INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT
Network Working Group G. Dudley
INTERNET DRAFT IBM
Category: Informational March 1998
APPN/HPR in IP Networks
APPN Implementers' Workshop Closed Pages Document
<draft-rfced-info-dudley-01.txt>
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this document is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 IP as a Data Link Control (DLC) for HPR . . . . . . . . . . . 3
2.1 Use of UDP and IP . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Node Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Logical Link Control (LLC) Used for IP . . . . . . . . . . . . 6
2.3.1 LDLC Liveness . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1.1 Option to Reduce Liveness Traffic . . . . . . . . . . 7
2.4 IP Port Activation . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Maximum BTU Sizes for HPR/IP . . . . . . . . . . . . . . . 10
2.5 IP Transmission Groups (TGs) . . . . . . . . . . . . . . . . . 10
2.5.1 Regular TGs . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1.1 Limited Resources and Auto-Activation . . . . . . . . 15
2.5.2 IP Connection Networks . . . . . . . . . . . . . . . . . . 16
2.5.2.1 Establishing IP Connection Networks . . . . . . . . . 17
2.5.2.2 IP Connection Network Parameters . . . . . . . . . . . 19
2.5.2.3 Sharing of TGs . . . . . . . . . . . . . . . . . . . . 20
2.5.2.4 Minimizing RSCV Length . . . . . . . . . . . . . . . . 21
2.5.3 Unsuccessful IP Link Activation . . . . . . . . . . . . . 22
2.6 IP Throughput Characteristics . . . . . . . . . . . . . . . . 24
2.6.1 IP Prioritization . . . . . . . . . . . . . . . . . . . . 24
2.6.2 APPN Transmission Priority and COS . . . . . . . . . . . . 25
2.6.3 Default TG Characteristics . . . . . . . . . . . . . . . . 26
2.6.4 SNA-Defined COS Tables . . . . . . . . . . . . . . . . . . 28
2.6.5 Route Setup over HPR/IP links . . . . . . . . . . . . . . 28
2.6.6 Access Link Queueing . . . . . . . . . . . . . . . . . . . 29
2.7 Port Link Activation Limits . . . . . . . . . . . . . . . . . 29
2.8 Network Management . . . . . . . . . . . . . . . . . . . . . . 30
2.9 IPv4-to-IPv6 Migration . . . . . . . . . . . . . . . . . . . . 31
3.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Dudley Informational [Page 1]
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . 32
5.0 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
6.0 Appendix - Packet Format . . . . . . . . . . . . . . . . . . . 33
6.1 HPR Use of IP Formats . . . . . . . . . . . . . . . . . . . . 33
6.1.1 IP Format for LLC Commands and Responses . . . . . . . . . 33
6.1.2 IP Format for NLPs in UI Frames . . . . . . . . . . . . . 35
7.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
1.0 Introduction
The APPN Implementers' Workshop (AIW) is an industry-wide consortium of
networking vendors that develops Advanced Peer-to-Peer Networking(R)
(APPN(R)) standards and other standards related to Systems Network
Architecture (SNA), and facilitates high quality, fully interoperable
APPN and SNA internetworking products. The AIW approved Closed Pages
(CP) status for the architecture in this document on December 2, 1997,
and, as a result, the architecture was added to the AIW architecture of
record. A CP-level document is sufficiently detailed that implementing
products will be able to interoperate; it contains a clear and complete
specification of all necessary changes to the architecture of record.
However, the AIW has procedures by which the architecture may be
modified, and the AIW is open to suggestions from the internet
community.
The architecture for APPN nodes is specified in "Systems Network
Architecture Advanced Peer-to-Peer Networking Architecture Reference"
[1]. A set of APPN enhancements for High Performance Routing (HPR) is
specified in "Systems Network Architecture Advanced Peer-to-Peer
Networking High Performance Routing Architecture Reference, Version 3.0"
[2]. The formats associated with these architectures are specified in
"Systems Network Architecture Formats" [3]. This memo assumes the
reader is familiar with these specifications.
This memo defines a method with which HPR nodes can use IP networks for
communication, and the enhancements to APPN required by this method.
This memo also describes an option set that allows the use of the APPN
connection network model to allow HPR nodes to use IP networks for
communication without having to predefine link connections.
(R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of the
IBM Corporation.
1.1 Requirements
The following are the requirements for the architecture specified in
this memo:
1. Facilitate APPN product interoperation in IP networks by documenting
agreements such as the choice of the logical link control (LLC).
Dudley Informational [Page 2]
2. Reduce system definition (e.g., by extending the connection network
model to IP networks) -- Connection network support is an optional
function.
3. Use class of service (COS) to retain existing path selection and
transmission priority services in IP networks; extend transmission
priority function to include IP networks.
4. Allow customers the flexibility to design their networks for low
cost and high performance.
5. Use HPR functions to improve both availability and scalability over
existing integration techniques such as Data Link Switching (DLSw)
which is specified in RFC 1795 [4] and RFC 2166 [5].
2.0 IP as a Data Link Control (DLC) for HPR
This memo specifies the use of IP and UDP as a new DLC that can be
supported by APPN nodes with the three HPR option sets: HPR (option set
1400), Rapid Transport Protocol (RTP) (option set 1401), and Control
Flows over RTP (option set 1402). Logical Data Link Control (LDLC)
Support (option set 2006) is also a prerequisite.
RTP is a connection-oriented, full-duplex protocol designed to transport
data in high-speed networks. HPR uses RTP connections to transport SNA
session traffic. RTP provides reliability (i.e., error recovery via
selective retransmission), in-order delivery (i.e., a first-in-first-out
[FIFO] service provided by resequencing data that arrives out of order),
and adaptive rate-based (ARB) flow/congestion control. Because RTP
provides these functions on an end-to-end basis, it eliminates the need
for these functions on the link level along the path of the connection.
The result is improved overall performance for HPR. For a more complete
description of RTP, see Appendix F of [2].
This new DLC (referred to as the native IP DLC) allows customers to take
advantage of APPN/HPR functions such as class of service (COS) and ARB
flow/congestion control in the IP environment. HPR links established
over the native IP DLC are referred to as HPR/IP links. The following
sections describe in detail the considerations and enhancements
associated with the native IP DLC.
2.1 Use of UDP and IP
The native IP DLC will use the User Datagram Protocol (UDP) defined in
RFC 768 [6] and the Internet Protocol (IP) version 4 defined in RFC 791
[7].
Typically, access to UDP is provided by a sockets API. UDP provides an
unreliable connectionless delivery service using IP to transport
messages between nodes. UDP has the ability to distinguish among
multiple destinations within a given node, and allows port-number-based
prioritization in the IP network. UDP provides detection of corrupted
packets, a function required by HPR. Higher-layer protocols such as HPR
Dudley Informational [Page 3]
are responsible for handling problems of message loss, duplication,
delay, out-of-order delivery, and loss of connectivity. UDP is adequate
because HPR uses RTP to provide end-to-end error recovery and in-order
delivery; in addition, LDLC detects loss of connectivity. The
Transmission Control Protocol (TCP) was not chosen for the native IP DLC
because the additional services provided by TCP such as error recovery
are not needed. Furthermore, the termination of TCP connections would
require additional node resources (control blocks, buffers, timers, and
retransmit queues) and would, thereby, reduce the scalability of the
design.
The UDP header has four two-byte fields. The UDP Destination Port is a
16-bit field that contains the UDP protocol port number used to
demultiplex datagrams at the destination. The UDP Source Port is a
16-bit field that contains the UDP protocol port number that specifies
the port to which replies should be sent when other information is not
available. A zero setting indicates that no source port number
information is being provided. When used with the native IP DLC, this
field is not used to convey a port number for replies; moreover, the
zero setting is not used. IANA has registered port numbers 12000
through 12004 for use in these two fields by the native IP DLC; use of
these port numbers allows prioritization in the IP network. For more
details of the use of these fields, see 2.6.1, "IP Prioritization" on
page 24.
The UDP Checksum is a 16-bit optional field that provides coverage of
the UDP header and the user data; it also provides coverage of a
pseudo-header that contains the source and destination IP addresses.
The UDP checksum is used to guarantee that the data has arrived intact
at the intended receiver. When the UDP checksum is set to zero, it
indicates that the checksum was not calculated and should not be checked
by the receiver. Use of the checksum is recommended for use with the
native IP DLC.
IP provides an unreliable, connectionless delivery mechanism. The IP
protocol defines the basic unit of data transfer through the IP network,
and performs the routing function (i.e., choosing the path over which
data will be sent). In addition, IP characterizes how "hosts" and
"gateways" should process packets, the circumstances under which error
messages are generated, and the conditions under which packets are
discarded. An IP version 4 header contains an 8-bit Type of Service
field that specifies how the datagram should be handled. As defined in
RFC 1349 [8], the type-of-service byte contains two defined fields. The
3-bit precedence field allows senders to indicate the priority of each
datagram. The 4-bit type of service field indicates how the network
should make tradeoffs between throughput, delay, reliability, and cost.
The 8-bit Protocol field specifies which higher-level protocol created
the datagram. When used with the native IP DLC, this field is set to 17
which indicates the higher-layer protocol is UDP.
2.2 Node Structure
Figure 1 on page 6 shows a possible node functional decomposition for
Dudley Informational [Page 4]
transport of HPR traffic across an IP network. There will be variations
in different platforms based on platform characteristics.
The native IP DLC includes a DLC manager, one LDLC component for each
link, and a link demultiplexor. Because UDP is a connectionless
delivery service, there is no need for HPR to activate and deactivate
lower-level connections.
The DLC manager activates and deactivates a link demultiplexor for each
port and an instance of LDLC for each link established in an IP network.
Multiple links (e.g., one defined link and one dynamic link for
connection network traffic) may be established between a pair of IP
addresses. Each link is identified by the source and destination IP
addresses in the IP header and the source and destination service access
point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0, "Appendix -
Packet Format" on page 33); the link demultiplexor passes incoming
packets to the correct instance of LDLC based on these identifiers.
Moreover, the IP address pair associated with an active link and used in
the IP header may not change.
LDLC also provides other functions (for example, reliable delivery of
Exchange Identification [XID] commands). Error recovery for HPR RTP
packets is provided by the protocols between the RTP endpoints.
The network control layer (NCL) uses the automatic network routing (ANR)
information in the HPR network header to either pass incoming packets to
RTP or an outgoing link.
All components are shown as single entities, but the number of logical
instances of each is as follows:
o DLC manager -- 1 per node
o LDLC -- 1 per link
o Link demultiplexor -- 1 per port
o NCL -- 1 per node (or 1 per port for efficiency)
o RTP -- 1 per RTP connection
o UDP -- 1 per port
o IP -- 1 per port
Products are free to implement other structures. Products implementing
other structures will need to make the appropriate modifications to the
algorithms and protocol boundaries shown in this document.
Dudley Informational [Page 5]
------------------------------------------------------------------------
-*
*-------------* *-------* |
|Configuration| | Path | |
| Services | |Control| |
*-------------* *-------* |
A A A |
| | | |
| | V |
| | *-----* | APPN/HPR
| | | RTP | |
| | *-----* |
| | A |
| | | |
| | V |
| | *-----* |
| | | NCL | |
| | *-----* |
| *------------* A -*
| | |
V V V -*
*---------* *---------* |
| DLC |--->| LDLC | |
| manager | | | |
*---------* *---------* |
| A | | IP DLC
*-----------* | *----* |
V | | |
*---------* | |
| LINK | | |
| DEMUX | | |
*---------* | |
A *-* -*
| |
| V
*---------*
| UDP |
*---------*
A
|
V
*---------*
| IP |
*---------*
------------------------------------------------------------------------
Figure 1. HPR/IP Node Structure
2.3 Logical Link Control (LLC) Used for IP
Logical Data Link Control (LDLC) is used by the native IP DLC. LDLC is
defined in [2]. LDLC uses a subset of the services defined by IEEE
Dudley Informational [Page 6]
802.2 LLC type 2 (LLC2). LDLC uses only the TEST, XID, DISC, DM, and UI
frames.
LDLC was defined to be used in conjunction with HPR (with the HPR
Control Flows over RTP option set 1402) over reliable links that do not
require link-level error recovery. Most frame loss in IP networks (and
the underlying frame networks) is due to congestion, not problems with
the facilities. When LDLC is used on a link, no link-level error
recovery is available; as a result, only RTP traffic is supported by the
native IP DLC. Using LDLC eliminates the need for LLC2 and its
associated cost (adapter storage, longer path length, etc.).
2.3.1 LDLC Liveness
LDLC liveness (using the LDLC TEST command and response) is required
when the underlying subnetwork does not provide notification of
connection outage. Because UDP is connectionless, it does not provide
outage notification; as a result, LDLC liveness is required for HPR/IP
links.
Liveness should be sent periodically on active links except as described
in the following subsection when the option to reduce liveness traffic
is implemented. The default liveness timer period is 10 seconds. When
the defaults for the liveness timer and retry timer (15 seconds) are
used, the period between liveness tests is smaller than the time
required to detect failure (retry count multiplied by retry timer
period) and may be smaller than the time for liveness to complete
successfully (on the order of round-trip delay). When liveness is
implemented as specified in the LDLC finite-state machine (see [2]) this
is not a problem because the liveness protocol works as follows: The
liveness timer is for a single link. The timer is started when the link
is first activated and each time a liveness test completes successfully.
When the timer expires, a liveness test is performed. When the link is
operational, the period between liveness tests is on the order of the
liveness timer period plus the round-trip delay.
For each implementation, it is necessary to check if the liveness
protocol will work in a satisfactory manner with the default settings
for the liveness and retry timers. If, for example, the liveness timer
is restarted immediately upon expiration, then a different default for
the liveness timer should be used.
2.3.1.1 Option to Reduce Liveness Traffic
In some environments, it is advantageous to reduce the amount of
liveness traffic when the link is otherwise idle. (For example, this
could allow underlying facilities to be temporarily deactivated when not
needed.) As an option, implementations may choose not to send liveness
when the link is idle (i.e., when data was neither sent nor received
over the link while the liveness timer was running). (If the
implementation is not aware of whether data has been received, liveness
testing may be stopped while data is not being sent.) However, the RTP
connections also have a liveness mechanism which will generate traffic.
Dudley Informational [Page 7]
Some implementations of RTP will allow setting a large value for the
ALIVE timer, thus reducing the amount of RTP liveness traffic.
If LDLC liveness is turned off while the link is idle, one side of the
link may detect a link failure much earlier than the other. This can
cause the following problems:
o If a node that is aware of a link failure attempts to reactivate the
link, the partner node (unaware of the link failure) may reject the
activation as an unsupported parallel link between the two ports.
o If a node that is unaware of an earlier link failure sends data
(including new session activations) on the link, it may be discarded
by a node that detected the earlier failure and deactivated the
link. As a result, session activations would fail.
The mechanisms described below can be used to remedy these problems.
These mechanisms are needed only in a node not sending liveness when the
link is idle; thus, they would not be required of a node not
implementing this option that just happened to be adjacent to a node
implementing the option.
o (Mandatory unless the node supports multiple active defined links
between a pair of HPR/IP ports and supports multiple active dynamic
links between a pair of HPR/IP ports.) Anytime a node rejects the
activation of an HPR/IP link as an unsupported parallel link between
a pair of HPR/IP ports (sense data X'10160045' or X'10160046'), it
should perform liveness on any active link between the two ports
that is using a different SAP pair. Thus, if the activation was not
for a parallel link but rather was a reactivation because one of
these active links had failed, the failed link will be detected.
(If the SAP pair for the link being activated matches the SAP pair
for an active link, a liveness test would succeed because the
adjacent node would respond for the link being activated.) A simple
way to implement this function is for LDLC, upon receiving an
activation XID, to run liveness on all active links with a matching
IP address pair and a different SAP pair.
o (Mandatory) Anytime a node receives an activation XID with an IP
address pair and a SAP pair that match those of an active link, it
should deactivate the active link and allow it to be reestablished.
A timer is required to prevent stray XIDs from deactivating an
active link.
o (Recommended) A node should attempt to reactivate an HPR/IP link
before acting on an LDLC-detected failure. This mechanism is
helpful in preventing session activation failures in scenarios where
the other side detected a link failure earlier, but the network has
recovered.
2.4 IP Port Activation
The node operator (NO) creates a native IP DLC by issuing DEFINE_DLC(RQ)
(containing customer-configured parameters) and START_DLC(RQ) commands
Dudley Informational [Page 8]
to the node operator facility (NOF). NOF, in turn, passes
DEFINE_DLC(RQ) and START_DLC(RQ) signals to configuration services (CS),
and CS creates the DLC manager. Then, the node operator can define a
port by issuing DEFINE_PORT(RQ) (also containing customer-configured
parameters) to NOF with NOF passing the associated signal to CS.
A node with adapters attached to multiple IP subnetworks may represent
the multiple adapters as a single HPR/IP port. However, in that case,
the node associates a single IP address with that port. RFC 1122 [9]
requires that a node with multiple adapters be able to use the same
source IP address on outgoing UDP packets regardless of the adapter used
for transmission.
*----------------------------------------------*
| NOF CS DLC |
*----------------------------------------------*
. DEFINE_DLC(RQ) .
1 o----------------->o
. DEFINE_DLC(RSP) |
2 o<-----------------*
. START_DLC(RQ) . create
3 o----------------->o------------------->o
. START_DLC(RSP) | .
4 o<-----------------* .
. DEFINE_PORT(RQ) . .
5 o----------------->o .
. DEFINE_PORT(RSP) | .
6 o<-----------------* .
Figure 2. IP Port Activation
The following parameters are received in DEFINE_PORT(RQ):
o Port name
o DLC name
o Port type (if IP connection networks are supported, set to shared
access transport facility [SATF]; otherwise, set to switched)
o Link station role (set to negotiable)
o Maximum receive BTU size (default is 1461 [1492 less an allowance
for the IP, UDP, and LLC headers])
o Maximum send BTU size (default is 1461 [1492 less an allowance for
the IP, UDP, and LLC headers])
o Link activation limits (total, inbound, and outbound)
o IPv4 supported (set to yes)
o The local IPv4 address (required if IPv4 is supported)
Dudley Informational [Page 9]
o IPv6 supported (set to no; may be set to yes in the future; see 2.9,
"IPv4-to-IPv6 Migration" on page 31)
o The local IPv6 address (required if IPv6 is supported)
o Retry count for LDLC (default is 3)
o Retry timer period for LDLC (default is 15 seconds; a smaller value
such as 10 seconds can be used for a campus network)
o LDLC liveness timer period (default is 10 seconds; see 2.3.1, "LDLC
Liveness" on page 7)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for the LLC commands such as XID and
for each of the APPN transmission priorities; the defaults are given
in 2.6.1, "IP Prioritization" on page 24.)
2.4.1 Maximum BTU Sizes for HPR/IP
When IP datagrams are larger than the underlying physical links support,
IP performs fragmentation. When HPR/IP links are established, the
default maximum basic transmission unit (BTU) sizes are 1461 bytes,
which corresponds to the typical IP maximum transmission unit (MTU) size
of 1492 bytes supported by routers on token-ring networks. 1461 is 1492
less 20 bytes for the IP header, 8 bytes for the UDP header, and 3 bytes
for the IEEE 802.2 LLC header. The IP header is larger than 20 bytes
when optional fields are included; smaller maximum BTU sizes should be
configured if optional IP header fields are used in the IP network. For
IPv6, the default is reduced to 1441 bytes to allow for the typical IPv6
header size of 40 bytes. Smaller maximum BTU sizes (but not less than
768) should be used to avoid fragmentation when necessary. Larger BTU
sizes should be used to improve performance when the customer's IP
network supports a sufficiently large IP MTU size. The maximum receive
and send BTU sizes are passed to CS in DEFINE_PORT(RQ). These maximum
BTU sizes can be overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ).
The Flags field in the IP header should be set to allow fragmentation.
Some products will not be able to control the setting of the bit
allowing fragmentation; in that case, fragmentation will most likely be
allowed. Although fragmentation is slow and prevents prioritization
based on UDP port numbers, it does allow connectivity across paths with
small MTU sizes.
2.5 IP Transmission Groups (TGs)
2.5.1 Regular TGs
Regular HPR TGs may be established in IP networks using the native IP
DLC architecture. Each of these TGs is composed of one or more HPR/IP
links. Configuration services (CS) identifies the TG with the
destination control point (CP) name and TG number; the destination CP
name may be configured or learned via XID, and the TG number, which may
Dudley Informational [Page 10]
be configured, is negotiated via XID. For auto-activatable links, the
destination CP name and TG number must be configured.
When multiple links (dynamic or defined) are established between a pair
of IP ports (each associated with a single IP address), an incoming
packet can be mapped to its associated link using the IP address pair
and the service access point (SAP) address pair. If a node receives an
activation XID for a defined link with an IP address pair and a SAP pair
that are the same as for an active defined link, that node can assume
that the link has failed and that the partner node is reactivating the
link. In such a case as an optimization, the node receiving the XID can
take down the active link and allow the link to be reestablished in the
IP network. Because UDP packets can arrive out of order, implementation
of this optimization requires the use of a timer to prevent a stray XID
from deactivating an active link.
Support for multiple defined links between a pair of HPR/IP ports is
optional. There is currently no value in defining multiple HPR/IP links
between a pair of ports. In the future if HPR/IP support for the
Resource ReSerVation Protocol (RSVP) [10] is defined, it may be
advantageous to define such parallel links to segregate traffic by COS
on RSVP "sessions." Using RSVP, HPR would be able to reserve bandwidth
in IP networks. An HPR logical link would be mapped to an RSVP
"session" that would likely be identified by either a specific
application-provided UDP port number or a dynamically-assigned UDP port
number.
When multiple defined HPR/IP links between ports are not supported, an
incoming activation for a defined HPR/IP link may be rejected with sense
data X'10160045' if an active defined HPR/IP link already exists between
the ports. If the SAP pair in the activation XID matches the SAP pair
for the existing link, the optimization described above may be used
instead.
If parallel defined HPR/IP links between ports are not supported, an
incoming activation XID is mapped to the defined link station (if it
exists) associated with the port on the adjacent node using the source
IP address in the incoming activation XID. This source IP address
should be the same as the destination IP address associated with the
matching defined link station. (They may not be the same if the
adjacent node has multiple IP addresses, and the configuration was not
coordinated correctly.)
If parallel HPR/IP links between ports are supported, multiple defined
link stations may be associated with the port on the adjacent node. In
that case, predefined TG numbers (see "Partitioning the TG Number Space"
in Chapter 9 Configuration Services of [1]) may be used to map the XID
to a specific link station. However, because the same TG
characteristics may be used for all HPR/IP links between a given pair of
ports, all the link stations associated with the port in the adjacent
node should be equivalent; as a result, TG number negotiation using
negotiable TG numbers may be used.
Dudley Informational [Page 11]
In the future, if multiple HPR/IP links with different characteristics
are defined between a pair of ports using RSVP, defined link stations
will need sufficient configured information to be matched with incoming
XIDs. (Correct matching of an incoming XID to a defined link station
allows CS to provide the correct TG characteristics to topology and
routing services (TRS).) At that time CS will do the mapping based on
both the IP address of the adjacent node and a predefined TG number.
The node initiating link activation knows which link it is activating.
Some parameters sent in prenegotiation XID are defined in the regular
link station configuration and not allowed to change in following
negotiation-proceeding XIDs. To allow for forward migration to RSVP,
when a regular TG is activated in an IP network, the node receiving the
first XID (i.e., the node not initiating link activation) must also
understand which defined link station is being activated before sending
a prenegotiation XID in order to correctly set parameters that cannot
change. For this reason, the node initiating link activation will
indicate the TG number in prenegotiation XIDs by including a TG
Descriptor (X'46') control vector containing a TG Identifier (X'80')
subfield. Furthermore, the node receiving the first XID will force the
node activating the link to send the first prenegotiation XID by
responding to null XIDs with null XIDs. To prevent potential deadlocks,
the node receiving the first XID has a limit (the LDLC retry count can
be used) on the number of null XIDs it will send. Once this limit is
reached, that node will send an XID with an XID Negotiation Error
(X'22') control vector in response to a null XID; sense data X'0809003A'
is included in the control vector to indicate unexpected null XID. If
the node that received the first XID receives a prenegotiation XID
without the TG Identifier subfield, it will send an XID with an XID
Negotiation Error control vector to reject the link connection; sense
data X'088C4680' is included in the control vector to indicate the
subfield was missing.
For a regular TG, the TG parameters are provided by the node operator
based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ).
The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP links:
o The destination IP host name (this parameter can usually be mapped
to the destination IP address): If the link is not activated at
node initialization, the IP host name should be mapped to an IP
address, and the IP address should be stored with the link station
definition. This is required to allow an incoming link activation
to be matched with the link station definition. If the adjacent
node activates the link with a different IP address (e.g., it could
have multiple ports), it will not be possible to match the link
activation with the link station definition, and the default
parameters specified in the local port definition will be used.
o The destination IP version (set to version 4, support for version 6
may be required in the future; this parameter is only required if
the address and version cannot be determined using the destination
IP host name.)
Dudley Informational [Page 12]
o The destination IP address (in the format specified by the
destination IP version; this parameter is only required if the
address cannot be determined using the destination IP host name.)
o Source service access point address (SSAP) used for XID, TEST, DISC,
and DM (default is X'04'; other values may be specified when
multiple links between a pair of IP addresses are defined)
o Destination service access point address (DSAP) used for XID, TEST,
DISC, and DM (default is X'04')
o Source service access point address (SSAP) used for HPR network
layer packets (NLPs) (default is X'C8'; other values may be
specified when multiple links between a pair of IP addresses are
defined.)
o Maximum receive BTU size (default is 1461; this parameter is used to
override the setting in DEFINE_PORT.)
o Maximum send BTU size (default is 1461; this parameter is used to
override the setting in DEFINE_PORT.)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for LLC commands such as XID and for
each of the APPN transmission priorities; the defaults are given in
2.6.1, "IP Prioritization" on page 24; this parameter is used to
override the settings in DEFINE_PORT)
o Shareable with connection network traffic (default is yes for
non-RSVP links)
o Retry count for LDLC (default is 3; this parameter is used to
override the setting in DEFINE_PORT)
o Retry timer period for LDLC (default is 15 seconds; a smaller value
such as 10 seconds can be used for a campus link; this parameter is
used to override the setting in DEFINE_PORT)
o LDLC liveness timer period (default is 10 seconds; this parameter is
used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC
Liveness" on page 7)
o Auto-activation supported (default is no; may be set to yes when the
local node has switched access to the IP network)
o Limited resource (default is to set in concert with auto-activation
supported)
o Limited resource liveness timer (default is 45 sec.)
o Port name
o Adjacent CP name (optional)
Dudley Informational [Page 13]
o Local CP-CP sessions supported
o Defined TG number (optional)
o TG characteristics
The following figures show the activation and deactivation of regular
TGs.
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
.CONNECT_OUT(RQ) . create . .
o--------------->o-------------->o . .
. | new LDLC . .
. o----------------------------->o .
CONNECT_OUT(+RSP)| . . .
o<---------------* . . .
| XID . XID(CMD) . XID
*------------------------------->o----------------------------->o----->
Figure 3. Regular TG Activation (outgoing)
In Figure 3 upon receiving START_LS(RQ) from NOF, CS starts the link
activation process by sending CONNECT_OUT(RQ) to the DLC manager. The
DLC manager creates an instance of LDLC for the link, informs the link
demultiplexor, and sends CONNECT_OUT(+RSP) to CS. Then, CS starts the
activation XID exchange.
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
. CONNECT_IN(RQ) . XID(CMD) . XID . XID
o<---------------o<-----------------------------o<--------------o<-----
| CONNECT_IN(RSP). create . .
*--------------->o-------------->o . .
. | new LDLC . .
. o----------------------------->o .
. | XID(CMD) . . .
. *-------------->o . .
. XID | . .
o<-------------------------------* . .
| XID . XID(RSP) . XID
*------------------------------->o----------------------------->o----->
Figure 4. Regular TG Activation (incoming)
In Figure 4, when an XID is received for a new link, it is passed to the
DLC manager. The DLC manager sends CONNECT_IN(RQ) to notify CS of the
incoming link activation, and CS sends CONNECT_IN(+RSP) accepting the
link activation. The DLC manager then creates a new instance of LDLC,
Dudley Informational [Page 14]
informs the link demultiplexor, and forwards the XID to to CS via LDLC.
CS then responds by sending an XID to the adjacent node.
The two following figures show normal TG deactivation (outgoing and
incoming).
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC
o------------------------------->o----------------------------->o----->
. DEACT . DM . DM . DM
o<-------------------------------o<-------------o<--------------o<-----
| DISCONNECT(RQ) . destroy . . .
*--------------->o-------------->o . .
DISCONNECT(RSP) | . .
o<---------------* . .
Figure 5. Regular TG Deactivation (outgoing)
In Figure 5 upon receiving STOP_LS(RQ) from NOF, CS sends DEACT to
notify the partner node that the HPR link is being deactivated. When
the response is received, CS sends DISCONNECT(RQ) to the DLC manager,
and the DLC manager deactivates the instance of LDLC. Upon receiving
DISCONNECT(RSP), CS sends STOP_LS(RSP) to NOF.
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC . DISC
o<-------------------------------o<-------------o<--------------o<-----
| . | DM . DM
| . *----------------------------->o----->
| DISCONNECT(RQ) . destroy . . .
*--------------->o-------------->o . .
.DISCONNECT(RSP) | . .
o<---------------* . .
Figure 6. Regular TG Deactivation (incoming)
In Figure 6, when an adjacent node deactivates a TG, the local node
receives a DISC. CS sends STOP_LS(IND) to NOF. Because IP is
connectionless, the DLC manager is not aware that the link has been
deactivated. For that reason, CS also needs to send DISCONNECT(RQ) to
the DLC manager; the DLC manager deactivates the instance of LDLC.
2.5.1.1 Limited Resources and Auto-Activation
To reduce tariff charges, the APPN architecture supports the definition
of switched links as limited resources. A limited-resource link is
deactivated when there are no sessions traversing the link.
Intermediate HPR nodes are not aware of sessions between logical units
Dudley Informational [Page 15]
(referred to as LU-LU sessions) carried in crossing RTP connections; in
HPR nodes, limited-resource TGs are deactivated when no traffic is
detected for some period of time. Furthermore, APPN links may be
defined as auto-activatable. Auto-activatable links are activated when
a new session has been routed across the link.
An HPR node may have access to an IP network via a switched access link.
In such environments, it may be advisable for customers to define
regular HPR/IP links as limited resources and as being auto-activatable.
2.5.2 IP Connection Networks
Connection network support for IP networks (option set 2010), is
described in this section.
APPN architecture defines single link TGs across the point-to-point
lines connecting APPN nodes. The natural extension of this model would
be to define a TG between each pair of nodes connected to a shared
access transport facility (SATF) such as a LAN or IP network. However,
the high cost of the system definition of such a mesh of TGs is
prohibitive for a network of more than a few nodes. For that reason,
the APPN connection network model was devised to reduce the system
definition required to establish TGs between APPN nodes.
Other TGs may be defined through the SATF which are not part of the
connection network. Such TGs (referred to as regular TGs in this
document) are required for sessions between control points (referred to
as CP-CP sessions) but may also be used for LU-LU sessions.
In the connection network model, a virtual routing node (VRN) is defined
to represent the SATF. Each node attached to the SATF defines a single
TG to the VRN rather than TGs to all other attached nodes.
Topology and routing services (TRS) specifies that a session is to be
routed between two nodes across a connection network by including the
connection network TGs between each of those nodes and the VRN in the
Route Selection control vector (RSCV). When a network node has a TG to
a VRN, the network topology information associated with that TG includes
DLC signaling information required to establish connectivity to that
node across the SATF. For an end node, the DLC signaling information is
returned as part of the normal directory services (DS) process. TRS
includes the DLC signaling information for TGs across connection
networks in RSCVs.
CS creates a dynamic link station when the next hop in the RSCV of an
ACTIVATE_ROUTE signal received from session services (SS) is a
connection network TG or when an adjacent node initiates link activation
upon receiving such an ACTIVATE_ROUTE signal. Dynamic link stations are
normally treated as limited resources, which means they are deactivated
when no sessions are using them. CP-CP sessions are not supported on
connections using dynamic link stations because CP-CP sessions normally
need to be kept up continuously.
Dudley Informational [Page 16]
Establishment of a link across a connection network normally requires
the use of CP-CP sessions to determine the destination IP address.
Because CP-CP sessions must flow across regular TGs, the definition of a
connection network does not eliminate the need to define regular TGs as
well.
Normally, one connection network is defined on a LAN (i.e., one VRN is
defined.) For an environment with several interconnected campus IP
networks, a single wide-area connection network can be defined; in
addition, separate connection networks can be defined between the nodes
connected to each campus IP network.
2.5.2.1 Establishing IP Connection Networks
Once the port is defined, a connection network can be defined on the
port. In order to support multiple TGs from a port to a VRN, the
connection network is defined by the following process:
1. A connection network and its associated VRN are defined on the port.
This is accomplished by the node operator issuing a
DEFINE_CONNECTION_NETWORK(RQ) command to NOF and NOF passing a
DEFINE_CN(RQ) signal to CS.
2. Each TG from the port to the VRN is defined by the node operator
issuing DEFINE_CONNECTION_NETWORK_TG(RQ) to NOF and NOF passing
DEFINE_CN_TG(RQ) to CS.
Prior to implementation of Resource ReSerVation Protocol (RSVP) support,
only one connection network TG between a port and a VRN is required. In
that case, product support for the DEFINE_CN_TG(RQ) signal is not
required because a single set of port configuration parameters for each
connection network is sufficient. If a NOF implementation does not
support DEFINE_CN_TG(RQ), the parameters listed in the following section
for DEFINE_CN_TG(RQ), are provided by DEFINE_CN(RQ) instead.
Furthermore, the Connection Network TG Numbers (X'81') subfield in the
TG Descriptor (X'46') control vector on an activation XID is only
required to support multiple connection network TGs to a VRN, and its
use is optional.
*-----------------------------------------------------*
| NO NOF CS |
*-----------------------------------------------------*
DEFINE_CONNECTION_NETWORK(RQ) DEFINE_CN(RQ) .
o------------------------>o----------------->o
DEFINE_CONNECTION_NETWORK(RSP) DEFINE_CN(RSP) |
o<------------------------o<-----------------*
DEFINE_CONNECTION_NETWORK_TG(RQ) DEFINE_CN_TG(RQ) .
o------------------------>o----------------->o
DEFINE_CONNECTION_NETWORK_TG(RSP) DEFINE_CN_TG(RSP)|
o<------------------------o<-----------------*
Figure 7. IP Connection Network Definition
Dudley Informational [Page 17]
An incoming dynamic link activation may be rejected with sense data
X'10160046' if there is an existing dynamic link between the two ports
over the same connection network (i.e., with the same VRN CP name). If
a node receives an activation XID for a dynamic link with an IP address
pair, a SAP pair, and a VRN CP name that are the same as for an active
dynamic link, that node can assume that the link has failed and that the
partner node is reactivating the link. In such a case as an
optimization, the node receiving the XID can take down the active link
and allow the link to be reestablished in the IP network. Because UDP
packets can arrive out of order, implementation of this optimization
requires the use of a timer to prevent a stray XID from deactivating an
active link.
Once all the connection networks are defined, the node operator issues
START_PORT(RQ), NOF passes the associated signal to CS, and CS passes
ACTIVATE_PORT(RQ) to the DLC manager. Upon receiving the
ACTIVATE_PORT(RSP) signal from the DLC manager, CS sends a TG_UPDATE
signal to TRS for each defined connection network TG. Each signal
notifies TRS that a TG to the VRN has been activated and includes TG
vectors describing the TG. If the port fails or is deactivated, CS
sends TG_UPDATE indicating the connection network TGs are no longer
operational. Information about TGs between a network node and the VRN
is maintained in the network topology database. Information about TGs
between an end node and the VRN is maintained only in the local topology
database. If TRS has no node entry in its topology database for the
VRN, TRS dynamically creates such an entry. A VRN node entry will
become part of the network topology database only if a network node has
defined a TG to the VRN; however, TRS is capable of selecting a direct
path between two end nodes across a connection network without a VRN
node entry.
*--------------------------------------------------------------------*
| CS TRS DLC DMUX |
*--------------------------------------------------------------------*
. ACTIVATE_PORT(RQ) . create
o--------------------------------------->o----------------->o
. ACTIVATE_PORT(RSP) | .
o<---------------------------------------* .
| TG_UPDATE . . .
*------------------->o . .
. . . .
Figure 8. IP Connection Network Establishment
The TG vectors for IP connection network TGs include the following
information:
o TG number
o VRN CP name
o TG characteristics used during route selection
- Effective capacity
Dudley Informational [Page 18]
- Cost per connect time
- Cost per byte transmitted
- Security
- Propagation delay
- User defined parameters
o Signaling information
- IP version (indicates the format of the IP header including the
IP address)
- IP address
- Link service access point address (LSAP) used for XID, TEST,
DISC, and DM
2.5.2.2 IP Connection Network Parameters
For a connection network TG, the parameters are determined by CS using
several inputs. Parameters that are particular to the local port,
connection network, or TG are system defined and received in
DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ). Signaling
information for the destination node including its IP address is
received in the ACTIVATE_ROUTE request from SS.
The following configuration parameters are received in DEFINE_CN(RQ):
o Connection network name (CP name of the VRN)
o Limited resource liveness timer (default is 45 sec.)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for LLC commands such as XID and for
each of the APPN transmission priorities; the defaults are given in
2.6.1, "IP Prioritization" on page 24; this parameter is used to
override the settings in DEFINE_PORT)
The following configuration parameters are received in DEFINE_CN_TG(RQ):
o Port name
o Connection network name (CP name of the VRN)
o Connection network TG number (set to a value between 1 and 239)
o TG characteristics (see 2.6.3, "Default TG Characteristics" on
page 26)
o Link service access point address (LSAP) used for XID, TEST, DISC,
and DM (default is X'04')
o Link service access point address (LSAP) used for HPR network layer
packets (default is X'C8')
Dudley Informational [Page 19]
o Limited resource (default is yes)
o Retry count for LDLC (default is 3; this parameter is used to
override the setting in DEFINE_PORT)
o Retry timer period for LDLC (default is 15 sec.; a smaller value
such as 10 seconds can be used for a campus connection network; this
parameter is used to override the setting in DEFINE_PORT)
o LDLC liveness timer period (default is 10 seconds; this parameter is
used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC
Liveness" on page 7)
o Shareable with other HPR traffic (default is yes for non-RSVP links)
o Maximum receive BTU size (default is 1461; this parameter is used to
override the value in DEFINE_PORT(RQ).)
o Maximum send BTU size (default is 1461; this parameter is used to
override the value in DEFINE_PORT(RQ).)
The following parameters are received in ACTIVATE_ROUTE for connection
network TGs:
o The TG pair
o The destination IP version (if this version is not supported by the
local node, the ACTIVATE_ROUTE_RSP reports the activation failure
with sense data X'086B46A5'.)
o The destination IP address (in the format specified by the
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.
Dudley Informational [Page 20]
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.
Dudley Informational [Page 21]
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 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 3). 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. | |
+--------------------------------------------------------+-------------+
Dudley Informational [Page 22]
+----------------------------------------------------------------------+
| Table 1 (Page 2 of 3). Native IP DLC Link Activation Failure Sense |
| Data |
+--------------------------------------------------------+-------------+
| ERROR DESCRIPTION | SENSE DATA |
+--------------------------------------------------------+-------------+
| 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. | |
+--------------------------------------------------------+-------------+
| 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. | |
+--------------------------------------------------------+-------------+
Dudley Informational [Page 23]
+----------------------------------------------------------------------+
| Table 1 (Page 3 of 3). Native IP DLC Link Activation Failure Sense |
| Data |
+--------------------------------------------------------+-------------+
| ERROR DESCRIPTION | SENSE DATA |
+--------------------------------------------------------+-------------+
| 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
Dudley Informational [Page 24]
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 |
+----------------------+----------------------+
| Network (LLC | 110 |
| commands and | |
| function-routed | |
| NLPs) | |
+----------------------+----------------------+
| 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
Dudley Informational [Page 25]
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
Dudley Informational [Page 26]
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:
Dudley Informational [Page 27]
+----------------------------------------------------------------------+
| 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
Dudley Informational [Page 28]
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 9. 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).
Dudley Informational [Page 29]
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
(available as RFC 2155 [11] in one of the repositories of IETF RFCs) and
the HPR MIB (available at
ftp://ietf.org/internet-drafts/draft-ietf-snanau-hprmib-02.txt). 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
Dudley Informational [Page 30]
associated with the local IP address for the port. If the agent
implements the IP-MIB (RFC 2011[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.
Dudley Informational [Page 31]
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", RFC 1795, April, 1995.
[5] Bryant, D., and P. Brittain, "APPN Implementers' Workshop Closed
Pages Document DLSw v2.0 Enhancements", RFC 2166, June, 1997.
[6] Postel, J., "User Datagram Protocol", RFC 768, August, 1980.
[7] Postel, J., "Internet Protocol", RFC 791, September, 1981.
[8] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC
1349, July, 1992.
[9] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC 1122, October, 1989.
[10] Braden, R., L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",
RFC 2205, September, 1997.
[11] Clouston, B., and B. Moore, "Definitions of Managed Objects for
APPN using SMIv2", RFC 2155, June, 1997.
[12] McCloghrie, K., "SNMPv2 Management Information Base for the
Internet Protocol using SMIv2", RFC 2011, November, 1996.
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
Dudley Informational [Page 32]
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) |
+-------+-----+--------------------------------------------------------+
Dudley Informational [Page 33]
+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 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 RFC 791. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 2: Rules for encoding the UDP header can be |
| | | found in RFC 768. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | 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. |
+-------+-----+--------------------------------------------------------+
Dudley Informational [Page 34]
+----------------------------------------------------------------------+
| 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 RFC 791. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 2: Rules for encoding the UDP header can be |
| | | found in RFC 768. |
+-------+-----+--------------------------------------------------------+
Dudley Informational [Page 35]
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 3: The User-Defined Address bit is considered |
| | | part of the DSAP. The Individual/Group bit in the |
| | | DSAP field is set to 0 by the sender and ignored by |
| | | the receiver. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 4: The User-Defined Address bit is considered |
| | | part of the SSAP. The Command/Response bit in the |
| | | SSAP field is set to 0 by the sender and ignored by |
| | | the receiver. |
+-------+-----+--------------------------------------------------------+
7.0 Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Dudley Informational [Page 36]
INTERNET DRAFT EXPIRES OCT 1998 INTERNET DRAFT