destination IP version)
o Destination service access point address (DSAP) used for XID,
TEST, DISC, and DM
2.5.2.3 Sharing of TGs
Connection network traffic is multiplexed onto a regular defined IP
TG (usually used for CP-CP session traffic) in order to reduce the
control block storage. No XIDs flow to establish a new TG on the IP
network, and no new LLC is created. When a regular TG is shared,
incoming traffic is demultiplexed using the normal means. If the
regular TG is deactivated, a path switch is required for the HPR
connection network traffic sharing the TG.
Multiplexing is possible if the following conditions hold:
1. Both the regular TG and the connection network TG to the VRN are
defined as shareable between HPR traffic streams.
2. The destination IP address is the same.
3. The regular TG is established first. (Because links established
for connection network traffic do not support CP-CP sessions,
there is little value in allowing a regular TG to share such a
link.)
The destination node is notified via XID when a TG can be shared
between HPR data streams. At either end, upon receiving
ACTIVATE_ROUTE requesting a shared TG for connection network traffic,
CS checks its TGs for one meeting the required specifications before
initiating a new link. First, CS looks for a link established for
the TG pair; if there is no such link, CS determines if there is a
regular TG that can be shared and, if multiple such TGs exist, which
TG to choose. As a result, RTP connections routed over the same TG
pair may actually use different links, and RTP connections routed
over different TG pairs may use the same link.
2.5.2.4 Minimizing RSCV Length
The maximum length of a Route Selection (X'2B') control vector (RSCV)
is 255 bytes. Use of connection networks significantly increases the
size of the RSCV contents required to describe a "hop" across an
SATF. First, because two connection network TGs are used to specify
an SATF hop, two TG Descriptor (X'46') control vectors are required.
Furthermore, inclusion of DLC signaling information within the TG
Descriptor control vectors increases the length of these control
vectors. As a result, the total number of hops that can be specified
in RSCVs traversing connection networks is reduced.
To avoid unnecessarily limiting the number of hops, a primary goal in
designing the formats for IP signaling information is to minimize
their size. Additional techniques are also used to reduce the effect
of the RSCV length limitation.
For an IP connection network, DLC signaling information is required
only for the second TG (i.e., from the VRN to the destination node);
the signaling information for the first TG is locally defined at the
origin node. For this reason, the topology database does not include
DLC signaling information for the entry describing a connection
network TG from a network node to a VRN. The DLC signaling
information is included in the allied entry for the TG in the
opposite direction. This mechanism cannot be used for a connection
network TG between a VRN and an end node. However, a node
implementing IP connection networks does not include IP signaling
information for the first connection network TG when constructing an
RSCV.
In an environment where APPN network nodes are used to route between
legacy LANs and wide-area IP networks, it is recommended that
customers not define connection network TGs between these network
nodes and VRNs representing legacy LANs. Typically, defined links
are required between end nodes on the legacy LANs and such network
nodes which also act as network node servers for the end nodes.
These defined links can be used for user traffic as well as control
traffic. This technique will reduce the number of connection network
hops in RSCVs between end nodes on different legacy LANs.
Lastly, for environments where RSCVs are still not able to include
enough hops, extended border nodes (EBNs) can be used to partition
the network. In this case, the EBNs will also provide piecewise
subnet route calculation and RSCV swapping. Thus, the entire route
does not need to be described in a single RSCV with its length
limitation.
2.5.3 XID Changes
Packets transmitted over IP networks are lost or arrive out of order
more often than packets transmitted over other "link" technologies.
As a result, the following problem with the XID3 negotiation protocol
was exposed:
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG)
o<-------------------------o
|XID3 (np, SEC)
*------------------------->o
XID3 (np, PRI)|
lost<-----------*
time out
XID3 (np, SEC)
o------------------------->o
SETMODE |
o<-------------------------*
fail because never
received XID3 (np, PRI)
Notation: np - negotiation proceeding
NEG - negotiable link station role
SEC - secondary link station role
PRI - primary link station role
--------------------------------------------------------------------
Figure 9. XID3 Protocol Problem
In the above sequence, the XID3(np, PRI), which is a link-level
response to the received XID3(np, SEC), is lost. Node A times out
and resends the XID3(np, SEC) as a link-level command. When Node B
receives this command, it thinks that the XID3(np, PRI) was
successfully received by Node A and that the activation XID exchange
is complete. As a result, Node B sends SETMODE (SNRM, SABME, or
XID_DONE_RQ, depending upon the link type). When Node A receives
SETMODE, it fails the link activation because it has not received an
XID3(np, PRI) from Node B confirming that Node B does indeed agree to
be the primary. Moreover, there are similar problems with incomplete
TG number negotiation.
To solve the problems with incomplete role and TG number negotiation,
two new indicators are defined in XID3. The problems are solved only
if both link stations support these new indicators:
o Negotiation Complete Supported indicator (byte 12 bit 0) -- this
1-bit field indicates whether the Negotiation Complete indicator
is supported. This field is meaningful when the XID exchange
state is negotiation proceeding; otherwise, it is reserved. A
value of 0 means the Negotiation Complete indicator is not
supported; a value of 1 means the indicator is supported.
o Negotiation Complete indicator (byte 12 bit 1) -- this 1-bit
field is meaningful only when the XID exchange state is
negotiation proceeding, the XID3 is sent by the secondary link
station, and the Negotiation Complete Supported indicator is set
to 1; otherwise, this field is reserved. This field is set to 1
by a secondary link station that supports enhanced XID
negotiation when it considers the activation XID negotiation to
be complete for both link station role and TG number (i.e., it is
ready to receive a SETMODE command from the primary link
station.)
When a primary link station that supports enhanced XID negotiation
receives an XID3(np) with both the Negotiation Complete Supported
indicator and the Negotiation Complete indicator set to 1, the
primary link station will know that it can safely send SETMODE if it
also considers the XID negotiation to be complete. The new
indicators are used as shown in the following sequence when both the
primary and secondary link stations support enhanced XID negotiation.
--------------------------------------------------------------------
*----------------------------------*
|Node A Node B |
*----------------------------------*
o
o
o
XID3 (np, NEG, S, ^C)
1 o<--------------------------o
|XID3 (np, SEC, S, ^C)
2 *-------------------------->o
XID3 (np, PRI, S, ^C)|
3 lost <-----------*
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
XID3 (np, PRI, S, ^C)|
5 o<--------------------------*
|XID3 (np, SEC, S, C)
6 *-------------------------->o
SETMODE |
7 o<--------------------------*
^S indicates that byte 12 bit 0 is set to 0.
S indicates that byte 12 bit 0 is set to 1.
^C indicates that byte 12 bit 1 is set to 0.
C indicates that byte 12 bit 1 is set to 1.
--------------------------------------------------------------------
Figure 10. Enhanced XID Negotiation
When Node B receives the XID in flow 4, it realizes that the Node A
does not consider XID negotiation to be complete; as a result, it
resends its current XID information in flow 5. When Node A receives
this XID, it responds in flow 6 with an XID that indicates XID
negotiation is complete. At this point, Node B, acting as the
primary link station, sends SETMODE, and the link is activated
successfully.
Migration cases with only one link station supporting enhanced XID
negotiation are shown in the two following sequences. In the next
sequence, only Node A (acting as the secondary link station) supports
the new function.
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG, ^S)
1 o<--------------------------o
|XID3 (np, SEC, S, ^C)
2 *-------------------------->o
XID3 (np, PRI, ^S)|
3 lost <-----------*
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
--------------------------------------------------------------------
Figure 11. First Migration Case
The XID negotiation fails because Node B does not understand the new
indicators and responds to flow 4 with SETMODE.
In the next sequence, Node B supports the new indicators but Node A
does not.
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG, S, ^C)
1 o<--------------------------o
|XID3 (np, SEC, ^S)
2 *-------------------------->o
XID3 (np, PRI, S, ^C)|
3 lost <-----------*
time out
XID3 (np, SEC, ^S)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
------------------------------------------------------------------------
Figure 12. Second Migration Case
The XID negotiation fails because Nobe A does not understand the new
indicators and thus cannot indicate that it thinks XID negotiation is
not complete in flow 4. Node B understands that the secondary link
station (node A) does not support the new indicators and respond with
SETMODE in flow 5.
Products that support HPR/IP links are required to support enhanced
XID negotiation. Moreover, it is recommended that products
implementing this solution for HPR/IP links also support it for other
link types.
2.5.4 Unsuccessful IP Link Activation
Link activation may fail for several different reasons. When link
activation over a connection network or of an auto-activatable link
is attempted upon receiving ACTIVATE_ROUTE from SS, activation
failure is reported with ACTIVATE_ROUTE_RSP containing sense data
explaining the cause of failure. Likewise, when activation fails for
other regular defined links, the failure is reported with
START_LS(RSP) containing sense data.
As is normal for session activation failures, the sense data is also
sent to the node that initiated the session. At the APPN-to-HPR
boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data
control vector is generated and returned to the primary logical unit
(PLU).
At an intermediate HPR node, link activation failure can be reported
with sense data X'08010000' or X'80020000'. At a node with route-
selection responsibility, such failure can be reported with sense
data X'80140001'.
The following table contains the sense data for the various causes of
link activation failure:
+----------------------------------------------------------------------+
| Table 1 (Page 1 of 2). Native IP DLC Link Activation Failure Sense |
| Data |
+--------------------------------------------------------+-------------+
| ERROR DESCRIPTION | SENSE DATA |
+--------------------------------------------------------+-------------+
| The link specified in the RSCV is not available. | X'08010000' |
+--------------------------------------------------------+-------------+
| The limit for null XID responses by a called node was | X'0809003A' |
| reached. | |
+--------------------------------------------------------+-------------+
| A BIND was received over a subarea link, but the next | X'08400002' |
| hop is over a port that supports only HPR links. The | |
| receiver does not support this configuration. | |
+--------------------------------------------------------+-------------+
| The contents of the DLC Signaling Type (X'91') | X'086B4691' |
| subfield of the TG Descriptor (X'46') control vector | |
| contained in the RSCV were invalid. | |
+--------------------------------------------------------+-------------+
| The contents of the IP Address and Link Service Access | X'086B46A5' |
| Point Address (X'A5') subfield of the TG Descriptor | |
| (X'46') control vector contained in the RSCV were | |
| invalid. | |
+--------------------------------------------------------+-------------+
| No DLC Signaling Type (X'91') subfield was found in | X'086D4691' |
| the TG Descriptor (X'46') control vector contained in | |
| the RSCV. | |
+--------------------------------------------------------+-------------+
| No IP Address and Link Service Access Point Address | X'086D46A5' |
| (X'A5') subfield was found in the TG Descriptor | |
| (X'46') control vector contained in the RSCV. | |
+--------------------------------------------------------+-------------+
| Multiple sets of DLC signaling information were found | X'08770019' |
| in the TG Descriptor (X'46') control vector contained | |
| in the RSCV. IP supports only one set of DLC | |
| signaling information. | |
+--------------------------------------------------------+-------------+
| Link Definition Error: A link is defined as not | X'08770026' |
| supporting HPR, but the port only supports HPR links. | |
+--------------------------------------------------------+-------------+
| A called node found no TG Identifier (X'80') subfield | X'088C4680' |
| within a TG Descriptor (X'46') control vector in a | |
| prenegotiation XID for a defined link in an IP | |
| network. | |
+--------------------------------------------------------+-------------+
+----------------------------------------------------------------------+
| Table 1 (Page 2 of 2). Native IP DLC Link Activation Failure Sense |
| Data |
+--------------------------------------------------------+-------------+
| The XID3 received from the adjacent node does not | X'10160031' |
| contain an HPR Capabilities (X'61') control vector. | |
| The IP port supports only HPR links. | |
+--------------------------------------------------------+-------------+
| The RTP Supported indicator is set to 0 in the HPR | X'10160032' |
| Capabilities (X'61') control vector of the XID3 | |
| received from the adjacent node. The IP port supports | |
| only links to nodes that support RTP. | |
+--------------------------------------------------------+-------------+
| The Control Flows over RTP Supported indicator is set | X'10160033' |
| to 0 in the HPR Capabilities (X'61') control vector of | |
| the XID3 received from the adjacent node. The IP port | |
| supports only links to nodes that support control | |
| flows over RTP. | |
+--------------------------------------------------------+-------------+
| The LDLC Supported indicator is set to 0 in the HPR | X'10160034' |
| Capabilities (X'61') control vector of the XID3 | |
| received from the adjacent node. The IP port supports | |
| only links to nodes that support LDLC. | |
+--------------------------------------------------------+-------------+
| The HPR Capabilities (X'61') control vector received | X'10160044' |
| in XID3 does not include an IEEE 802.2 LLC (X'80') HPR | |
| Capabilities subfield. The subfield is required on an | |
| IP link. | |
+--------------------------------------------------------+-------------+
| Multiple defined links between a pair of switched | X'10160045' |
| ports is not supported by the local node. A link | |
| activation request was received for a defined link, | |
| but there is an active defined link between the paired | |
| switched ports. | |
+--------------------------------------------------------+-------------+
| Multiple dynamic links across a connection network | X'10160046' |
| between a pair of switched ports is not supported by | |
| the local node. A link activation request was | |
| received for a dynamic link, but there is an active | |
| dynamic link between the paired switched ports across | |
| the same connection network. | |
+--------------------------------------------------------+-------------+
| Link failure | X'80020000' |
+--------------------------------------------------------+-------------+
| Route selection services has determined that no path | X'80140001' |
| to the destination node exists for the specified COS. | |
+--------------------------------------------------------+-------------+
2.6 IP Throughput Characteristics
2.6.1 IP Prioritization
Typically, IP routers process packets on a first-come-first-served
basis; i.e., no packets are given transmission priority. However,
some IP routers prioritize packets based on IP precedence (the 3-bit
field within the Type of Service byte of the IP header) or UDP port
numbers. (With the current plans for IP security, the UDP port
numbers are encrypted; as a result, IP routers would not be able to
prioritize encrypted traffic based on the UDP port numbers.) HPR
will be able to exploit routers that provide priority function.
The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by
the Internet Assigned Number Authority (IANA). Four of these port
numbers are used for ANR-routed network layer packets (NLPs) and
correspond to the APPN transmission priorities (network, 12001; high,
12002; medium, 12003; and low, 12004), and one port number (12000) is
used for a set of LLC commands (i.e., XID, TEST, DISC, and DM) and
function-routed NLPs (i.e., XID_DONE_RQ and XID_DONE_RSP). These
port numbers are used for "listening" and are also used in the
destination port number field of the UDP header of transmitted
packets. The source port number field of the UDP header can be set
either to one of these port numbers or to an ephemeral port number.
The IP precedence for each transmission priority and for the set of
LLC commands (including function-routed NLPs) are configurable. The
implicit assumption is that the precedence value is associated with
priority queueing and not with bandwidth allocation; however,
bandwidth allocation policies can be administered by matching on the
precedence field. The default mapping to IP precedence is shown in
the following table:
+---------------------------------------------+
| Table 2. Default IP Precedence Settings |
+----------------------+----------------------+
| PRIORITY | PRECEDENCE |
+----------------------+----------------------+
| LLC commands and | 110 |
| function-routed NLPs | |
+----------------------+----------------------+
| Network | 110 |
+----------------------+----------------------+
| High | 100 |
+----------------------+----------------------+
| Medium | 010 |
+----------------------+----------------------+
| Low | 001 |
+----------------------+----------------------+
As an example, with this default mapping, telnet, interactive ftp,
and business-use web traffic could be mapped to a precedence value of
011, and batch ftp could be mapped to a value of 000.
These settings were devised based on the AIW's understanding of the
intended use of IP precedence. The use of IP precedence will be
modified appropriately if the IETF standardizes its use differently.
The other fields in the IP TOS byte are not used and should be set to
0.
For outgoing ANR-routed NLPs, the destination (and optionally the
source) UDP port numbers and IP precedence are set based on the
transmission priority specified in the HPR network header.
It is expected that the native IP DLC architecture described in this
document will be used primarily for private campus or wide-area
intranets where the customer will be able to configure the routers to
honor the transmission priority associated with the UDP port numbers
or IP precedence. The architecture can be used to route HPR traffic
in the Internet; however, in that environment, routers do not
currently provide the priority function, and customers may find the
performance unacceptable.
In the future, a form of bandwidth reservation may be possible in IP
networks using the Resource ReSerVation Protocol (RSVP), or the
differentiated services currently being studied by the Integrated
Services working group of the IETF. Bandwidth could be reserved for
an HPR/IP link thus insulating the HPR traffic from congestion
associated with the traffic of other protocols.
2.6.2 APPN Transmission Priority and COS
APPN transmission priority and class of service (COS) allow APPN TGs
to be highly utilized with batch traffic without impacting the
performance of response-time sensitive interactive traffic.
Furthermore, scheduling algorithms guarantee that lower-priority
traffic is not completely blocked. The result is predictable
performance.
When a session is initiated across an APPN network, the session's
mode is mapped into a COS and transmission priority. For each COS,
APPN has a COS table that is used in the route selection process to
select the most appropriate TGs (based on their TG characteristics)
for the session to traverse. The TG characteristics and COS tables
are defined such that APPN topology and routing services (TRS) will
select the appropriate TG for the traffic of each COS.
2.6.3 Default TG Characteristics
In Chapter 7 (TRS) of [1], there is a set of SNA-defined TG default
profiles. When a TG (connection network or regular) is defined as
being of a particular technology (e.g., ethernet or X.25) without
specification of the TG's characteristics, parameters from the
technology's default profile are used in the TG's topology entry.
The customer is free to override these values via configuration.
Some technologies have multiple profiles (e.g., ISDN has both a
profile for switched and nonswitched.) Two default profiles are
required for IP TGs. This many are needed because there are both
campus and wide-area IP networks. As a result for each HPR/IP TG, a
customer should specify, at minimum, campus or wide area. HPR/IP TGs
traversing the Internet should be specified as wide-area links. If
no specification is made, a campus network is assumed.
The 2 IP profiles are as follows:
+----------------------------------------------------------------------+
| Table 3. IP Default TG Characteristics |
+-------------------+---------+----------+---------+---------+---------+
| | Cost | Cost per | Security| Propa- | Effec- |
| | per | byte | | gation | tive |
| | connect | | | delay | capacity|
| | time | | | | |
+-------------------+---------+----------+---------+---------+---------+
| Campus | 0 | 0 | X'01' | X'71' | X'75' |
+-------------------+---------+----------+---------+---------+---------+
| Wide area | 0 | 0 | X'20' | X'91' | X'43' |
+-------------------+---------+----------+---------+---------+---------+
Typically, a TG is either considered to be "free" if it is owned or
leased or "costly" if it is a switched carrier facility. Free TGs
have 0 for both cost parameters, and costly TGs have 128 for both
parameters. For campus IP networks, the default for both cost
parameters is 0.
It is less clear what the defaults should be for wide area. Because
a router normally has leased access to an IP network, the defaults
for both costs are also 0. This assumes the IP network is not
tariffed. However, if the IP network is tariffed, then the customer
should set the cost per byte to 0 or 128 depending on whether the
tariff contains a component based on quantity of data transmitted,
and the customer should set the cost per connect time to 0 or 128
based on whether there is a tariff component based on connect time.
Furthermore, for switched access to the IP network, the customer
settings for both costs should also reflect the tariff associated
with the switched access link.
Only architected values (see "Security" in [1]) may be used for a
TG's security parameter. The default security value is X'01'
(lowest) for campus and X'20' (public switched network; secure in the
sense that there is no predetermined route the traffic will take) for
wide-area IP networks. The network administrator may override the
default value but should, in that case, ensure that an appropriate
level of security exists.
For wide area, the value X'91' (packet switched) is the default for
propagation delay; this is consistent with other wide-area facilities
and indicates that IP packets will experience both terrestrial
propagation delay and queueing delay in intermediate routers. This
value is suitable for both the Internet and wide-area intranets;
however, the customer could use different values to favor intranets
over the Internet during route selection. The value X'99' (long) may
be appropriate for some international links across the Internet. For
campus, the default is X'71' (terrestrial); this setting essentially
equates the queueing delay in IP networks with terrestrial
propagation delay.
For wide area, X'43' (56 kbs) is shown as the default effective
capacity; this is at the low-end of typical speeds for wide-area IP
links. For campus, X'75' (4 Mbs) is the default; this is at the
low-end of typical speeds for campus IP links. However, customers
should set the effective capacity for both campus and wide area IP
links based on the actual physical speed of the access link to the IP
network; for regular links, if both the source and destination access
speeds are known, customers should set the effective capacity based
on the minimum of these two link speeds. If there are multiple
access links, the capacity setting should be based on the physical
speed of the access link that is expected to be used for the link.
For the encoding technique for effective capacity in the topology
database, see "Effective Capacity" in Chapter 7, Topology and Routing
Services of [1]. The table in that section can be extended as
follows for higher speeds:
+----------------------------------------------------------------------+
| Table 4. Calculated Effective Capacity Representations |
+-----------------------------------+----------------------------------+
| Link Speed (Approx.) | Effective Capacity |
+-----------------------------------+----------------------------------+
| 25M | X'8A' |
+-----------------------------------+----------------------------------+
| 45M | X'91' |
+-----------------------------------+----------------------------------+
| 100M | X'9A' |
+-----------------------------------+----------------------------------+
| 155M | X'A0' |
+-----------------------------------+----------------------------------+
| 467M | X'AC' |
+-----------------------------------+----------------------------------+
| 622M | X'B0' |
+-----------------------------------+----------------------------------+
| 1G | X'B5' |
+-----------------------------------+----------------------------------+
| 1.9G | X'BC' |
+-----------------------------------+----------------------------------+
2.6.4 SNA-Defined COS Tables
SNA-defined batch and interactive COS tables are provided in [1].
These tables are enhanced in [2] (see section 18.7.2) for the
following reasons:
o To ensure that the tables assign reasonable weights to ATM TGs
relative to each other and other technologies based on cost,
speed, and delay
o To facilitate use of other new higher-speed facilities - This
goal is met by providing several speed groupings above 10 Mbps.
To keep the tables from growing beyond 12 rows, low-speed
groupings are merged.
Products implementing the native IP DLC should use the new COS
tables. Although the effective capacity values in the old tables are
sufficient for typical IP speeds, the new tables are valuable because
higher-speed links can be used for IP networks.
2.6.5 Route Setup over HPR/IP links
The Resequence ("REFIFO") indicator is set in Route Setup request and
reply when the RTP path uses a multi-link TG because packets may not
be received in the order sent. The Resequence indicator is also set
when the RTP path includes an HPR/IP link as packets sent over an IP
network may arrive out of order.
Adaptive rate-based congestion control (ARB) is an HPR Rapid
Transport Protocol (RTP) function that controls the data transmission
rate over RTP connections. ARB also provides fairness between the
RTP traffic streams sharing a link. For ARB to perform these
functions in the IP environment, it is necessary to coordinate the
ARB parameters with the IP TG characteristics. This is done for IP
links in a similar manner to that done for other link types.
2.6.6 Access Link Queueing
Typically, nodes implementing the native IP DLC have an access link
to a network of IP routers. These IP routers may be providing
prioritization based on UDP port numbers or IP precedence. A node
implementing the native IP DLC can be either an IP host or an IP
router; in both cases, such nodes should also honor the priorities
associated with either the UDP port numbers or the IP precedence when
transmitting HPR data over the access link to the IP network.
--------------------------------------------------------------------
*--------* access link *--------* *--------*
| HPR |-------------| IP |-----| IP |
| node | | Router | | Router |
*--------* *--------* *--------*
| |
| |
| |
*--------* *--------* access link *--------*
| IP |-----| IP |-------------| HPR |
| Router | | Router | | node |
*--------* *--------* *--------*
--------------------------------------------------------------------
Figure 13. Access Links
Otherwise, the priority function in the router network will be
negated with the result being HPR interactive traffic delayed by
either HPR batch traffic or the traffic of other higher-layer
protocols at the access link queues.
2.7 Port Link Activation Limits
Three parameters are provided by NOF to CS on DEFINE_PORT(RQ) to
define the link activation limits for a port: total limit, inbound
limit, and outbound limit. The total limit is the desired maximum
number of active link stations allowed on the port for both regular
TGs and connection network TGs. The inbound limit is the desired
number of link stations reserved for connections initiated by
adjacent nodes; the purpose of this field is to insure that a minimum
number of link stations may be activated by adjacent nodes. The
outbound limit is the desired number of link stations reserved for
connections initiated by the local node. The sum of the inbound and
outbound limits must be less than or equal to the total limit. If
the sum is less than the total limit, the difference is the number of
link stations that can be activated on a demand basis as either
inbound or outbound. These limits should be based on the actual
adapter capability and the node's resources (e.g., control blocks).
A connection network TG will be reported to topology as quiescing
when its port's total limit threshold is reached; likewise, an
inactive auto-activatable regular TG is reported as nonoperational.
When the number of active link stations drops far enough below the
threshold (e.g., so that at least 20 percent of the original link
activation limit has been recovered), connection network TGs are
reported as not quiescing, and auto-activatable TGs are reported as
operational.
2.8 Network Management
APPN and HPR management information is defined by the APPN MIB (RFC
2155 [11]) and the HPR MIB (RFC2238 [13]). In addition, the SNANAU
working group of the IETF plans to define an HPR-IP-MIB that will
provide HPR/IP-specific management information. In particular, this
MIB will provide a mapping of APPN traffic types to IP Type of
Service Precedence values, as well as a count of UDP packets sent for
each traffic type.
There are also rules that must be specified concerning the values an
HPR/IP implementation returns for objects in the APPN MIB:
o Several objects in the APPN MIB have the syntax IANAifType. The
value 126, defined as "IP (for APPN HPR in IP networks)" should
be returned by the following three objects when they identify an
HPR/IP link:
- appnPortDlcType
- appnLsDlcType
- appnLsStatusDlcType
o Link-level addresses are reported in the following objects:
- appnPortDlcLocalAddr
- appnLsLocalAddr
- appnLsRemoteAddr
- appnLsStatusLocalAddr
- appnLsStatusRemoteAddr
All of these objects should return ASCII character strings that
represent IP addresses in the usual dotted-decimal format. (At
this point it's not clear what the "usual...format" will be for
IPv6 addresses, but whatever it turns out to be, that is what
these objects will return when an HPR/IP link traverses an IP
network.)
o The following two objects return Object Identifiers that tie
table entries in the APPN MIB to entries in lower-layer MIBs:
- appnPortSpecific
- appnLsSpecific
Both of these objects should return the same value: a RowPointer
to the ifEntry in the agent's ifTable for the physical interface
associated with the local IP address for the port. If the agent
implements the IP-MIB (RFC2011 [12]), this association between
the IP address and the physical interface will be represented in
the ipNetToMediaTable.
2.9 IPv4-to-IPv6 Migration
The native IP DLC is architected to use IP version 4 (IPv4).
However, support for IP version 6 (IPv6) may be required in the
future.
IP routers and hosts can interoperate only if both ends use the same
version of the IP protocol. However, most IPv6 implementations
(routers and hosts) will actually have dual IPv4/IPv6 stacks. IPv4
and IPv6 traffic can share transmission facilities provided that the
router/host at each end has a dual stack. IPv4 and IPv6 traffic will
coexist on the same infrastructure in most areas. The version number
in the IP header is used to map incoming packets to either the IPv4
or IPv6 stack. A dual-stack host which wishes to talk to an IPv4
host will use IPv4.
Hosts which have an IPv4 address can use it as an IPv6 address using
a special IPv6 address prefix (i.e., it is an embedded IPv4 address).
This mapping was provided mainly for "legacy" application
compatibility purposes as such applications don't have the socket
structures needed to store full IPv6 addresses. Two IPv6 hosts may
communicate using IPv6 with embedded-IPv4 addresses.
Both IPv4 and IPv6 addresses can be stored by the domain name service
(DNS). When an application queries DNS, it asks for IPv4 addresses,
IPv6 addresses, or both. So, it's the application that decides which
stack to use based on which addresses it asks for.
Migration for HPR/IP ports will work as follows:
An HPR/IP port is configured to support IPv4, IPv6, or both. If IPv4
is supported, a local IPv4 address is defined; if IPv6 is supported,
a local IPv6 address (which can be an embedded IPv4 address) is
defined. If both IPv4 and IPv6 are supported, both a local IPv4
address and a local IPv6 address are defined.
Defined links will work as follows: If the local node supports IPv4
only, a destination IPv4 address may be defined, or an IP host name
may be defined in which case DNS will be queried for an IPv4 address.
If the local node supports IPv6 only, a destination IPv6 address may
be defined, or an IP host name may be defined in which case DNS will
be queried for an IPv6 address. If both IPv4 and IPv6 are supported,
a destination IPv4 address may be defined, a destination IPv6 address
may be defined, or an IP host name may be defined in which case DNS
will be queried for both IPv4 and IPv6 addresses; if provided by DNS,
an IPv6 address can be used, and an IPv4 address can be used
otherwise.
Separate IPv4 and IPv6 connection networks can be defined. If the
local node supports IPv4, it can define a connection network TG to
the IPv4 VRN. If the local node supports IPv6, it can define a TG to
the IPv6 VRN. If both are supported, TGs can be defined to both
VRNs. Therefore, the signaling information received in RSCVs will be
compatible with the local node's capabilities unless a configuration
error has occurred.
3.0 References
[1] IBM, Systems Network Architecture Advanced Peer-to-Peer
Networking Architecture Reference, SC30-3442-04. Viewable at URL:
http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS
[2] IBM, Systems Network Architecture Advanced Peer-to-Peer
Networking High Performance Routing Architecture Reference, Version
3.0, SV40-1018-02. Viewable at URL: http://www.raleigh.ibm.com/cgi-
bin/bookmgr/BOOKS/D50H6001/CCONTENTS
[3] IBM, Systems Network Architecture Formats, GA27-3136-16.
Viewable at URL: http://www.raleigh.ibm.com/cgi-
bin/bookmgr/BOOKS/D50A5003/CCONTENTS
[4] Wells, L. and A. Bartky, "Data Link Switching: Switch-to-Switch
Protocol, AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version
1.0", RFC1795, April 1995.
[5] Bryant, D. and P. Brittain, "APPN Implementers' Workshop Closed
Pages Document DLSw v2.0 Enhancements", RFC2166, June 1997.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[7] Postel, J., "Internet Protocol", STD 5, RFC791, September 1981.
[8] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC1349, July 1992.
[9] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[10] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC2205, September 1997.
[11] Clouston, B., and B. Moore, "Definitions of Managed Objects for
APPN using SMIv2", RFC2155, June 1997.
[12] McCloghrie, K., "SNMPv2 Management Information Base for the
Internet Protocol using SMIv2", RFC2011, November 1996.
[13] Clouston, B., and B. Moore, "Definitions of Managed Objects for
HPR using SMIv2", RFC2238, November 1997.
4.0 Security Considerations
For HPR, the IP network appears to be a link. For that reason, the
SNA session-level security functions (user authentication, LU
authentication, session encryption, etc.) are still available for
use. In addition, as HPR traffic flows as UDP datagrams through the
IP network, IPsec can be used to provide network-layer security
inside the IP network.
There are firewall considerations when supporting HPR traffic using
the native IP DLC. First, the firewall filters can be set to allow
the HPR traffic to pass. Traffic can be restricted based on the
source and destination IP addresses and the destination port number;
the source port number is not relevant. That is, the firewall should
accept traffic with the IP addresses of the HPR/IP nodes and with
destination port numbers in the range 12000 to 12004. Second, the
possibility exists for an attack using forged UDP datagrams; such
attacks could cause the RTP connection to fail or even introduce
false data on a session. In environments where such attacks are
expected, the use of network-layer security is recommended.
5.0 Author's Address
Gary Dudley
C3BA/501
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709, USA
Phone: +1 919-254-4358
Fax: +1 919-254-6243
EMail: dudleyg@us.ibm.com
6.0 Appendix - Packet Format
6.1 HPR Use of IP Formats
+----------------------------------------------------------------------+
| 6.1.1 IP Format for LLC Commands and Responses |
| |
| The formats described here are used for the |
| following LLC commands and responses: XID |
| command and response, TEST command and response, |
| DISC command, and DM response. |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p | | IP header (see note 1) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1- | | UDP header (see note 2) |
| p+8 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9- | | IEEE 802.2 LLC header (see note 3) |
_____________________
| p+11 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9 | | DSAP: same as for the base APPN (i.e., X'04' or an |
| | | installation-defined value) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+10 | | SSAP: same as for the base APPN (i.e., X'04' or an |
| | | installation-defined value) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+11 | | Control: set as appropriate |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+12-n| | Remainder of PDU: XID3 or TEST information field, or |
| | | null for DISC command and DM response |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 1: Rules for encoding the IP header can be found |
| | | in RFC791. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 2: Rules for encoding the UDP header can be |
| | | found in RFC768. |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 3: Rules for encoding the IEEE 802.2 LLC header |
| | | can be found in ISO/IEC 8802-2:1994 (ANSI/IEEE Std |
| | | 802.2, 1994 Edition), Information technology - |
| | | Telecommunications and information exchange between |
| | | systems - Local and metropolitan area networks - |
| | | Specific requirements - Part 2: Logical Link Control. |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 6.1.2 IP Format for NLPs in UI Frames |
| |
| This format is used for either LDLC specific |
| messages or HPR session and control traffic. |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p | | IP header (see note 1) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1- | | UDP header (see note 2) |
| p+8 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9- | | IEEE 802.2 LLC header |
_____________________
| p+11 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9 | | DSAP: the destination SAP obtained from the IEEE |
| | | 802.2 LLC (X'80') subfield in the HPR Capabilities |
| | | (X'61') control vector in the received XID3 (see note |
| | | 3) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+10 | | SSAP: the source SAP obtained from the IEEE 802.2 LLC |
| | | (X'80') subfield in the HPR Capabilities (X'61') |
| | | control vector in the sent XID3 (see note 4) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+11 | | Control: |
+-------+-----+-------+------------------------------------------------+
| | | X'03' | UI with P/F bit off |
+-------+-----+-------+------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+12-n| | Remainder of PDU: NLP |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 1: Rules for encoding the IP header can be found |
| | | in RFC791. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 2: Rules for encoding the UDP header can be |
| | | found in RFC768. |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+