RFC 2353
APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document
RFC 2353: APPN/HPR in IP Networks 🎀
Okay bestie, this one is RFC 2353 💖 The title is APPN/HPR in IP Networks, with the subtitle APPN Implementers' Workshop Closed Pages Document ✨ G. Dudley wrote it at IBM 💼 It's dated May 1998, and its category is Informational 📚 That means it's here to inform the internet community, not to be an official standard. Its header has no Obsoletes or Updates lines, so it doesn't replace or change any other RFC 🦋
Status of this Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (1998). All Rights Reserved.
Table of Contents 🧚
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 IP as a Data Link Control (DLC) for HPR . . . . . . . . . 3
2.1 Use of UDP and IP . . . . . . . . . . . . . . . . . . . . 4
2.2 Node Structure . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Logical Link Control (LLC) Used for IP . . . . . . . . . . 8
2.3.1 LDLC Liveness . . . . . . . . . . . . . . . . . . . . 8
2.3.1.1 Option to Reduce Liveness Traffic . . . . . . . . 9
2.4 IP Port Activation . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Maximum BTU Sizes for HPR/IP . . . . . . . . . . . . . 12
2.5 IP Transmission Groups (TGs) . . . . . . . . . . . . . . . 12
2.5.1 Regular TGs . . . . . . . . . . . . . . . . . . . . . 12
2.5.1.1 Limited Resources and Auto-Activation . . . . . . 19
2.5.2 IP Connection Networks . . . . . . . . . . . . . . . . 19
2.5.2.1 Establishing IP Connection Networks . . . . . . . 20
2.5.2.2 IP Connection Network Parameters . . . . . . . . . 22
2.5.2.3 Sharing of TGs . . . . . . . . . . . . . . . . . . 24
2.5.2.4 Minimizing RSCV Length . . . . . . . . . . . . . . 25
2.5.3 XID Changes . . . . . . . . . . . . . . . . . . . . . 26
2.5.4 Unsuccessful IP Link Activation . . . . . . . . . . . 30
2.6 IP Throughput Characteristics . . . . . . . . . . . . . . 34
2.6.1 IP Prioritization . . . . . . . . . . . . . . . . . . 34
2.6.2 APPN Transmission Priority and COS . . . . . . . . . . 36
2.6.3 Default TG Characteristics . . . . . . . . . . . . . . 36
2.6.4 SNA-Defined COS Tables . . . . . . . . . . . . . . . . 38
2.6.5 Route Setup over HPR/IP links . . . . . . . . . . . . 39
2.6.6 Access Link Queueing . . . . . . . . . . . . . . . . . 39
2.7 Port Link Activation Limits . . . . . . . . . . . . . . . 40
2.8 Network Management . . . . . . . . . . . . . . . . . . . . 40
2.9 IPv4-to-IPv6 Migration . . . . . . . . . . . . . . . . . . 41
3.0 References . . . . . . . . . . . . . . . . . . . . . . . . 42
4.0 Security Considerations . . . . . . . . . . . . . . . . . 43
5.0 Author's Address . . . . . . . . . . . . . . . . . . . . . 44
6.0 Appendix - Packet Format . . . . . . . . . . . . . . . . . 45
6.1 HPR Use of IP Formats . . . . . . . . . . . . . . . . . . 45
6.1.1 IP Format for LLC Commands and Responses . . . . . . . 45
6.1.2 IP Format for NLPs in UI Frames . . . . . . . . . . . 46
7.0 Full Copyright Statement . . . . . . . . . . . . . . . . . 481.0 Introduction 💅
The APPN Implementers' Workshop (AIW) is an industry-wide consortium of networking vendors. It develops Advanced Peer-to-Peer Networking(R) (APPN(R)) standards and other standards related to Systems Network Architecture (SNA), and it helps make APPN and SNA internetworking products highly interoperable 🫶 On December 2, 1997, the AIW approved Closed Pages (CP) status for the architecture in this document, so the architecture was added to the AIW architecture of record 🎉 A CP-level document is detailed enough that implementing products will be able to interoperate. It has a clear and complete specification of all necessary changes to the architecture of record. The AIW does have procedures for modifying the architecture, and it's 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 for these architectures are specified in "Systems Network Architecture Formats" [3]. This memo assumes you already know these specs, bestie 🤓
This memo defines a method that lets HPR nodes use IP networks for communication, along with the APPN enhancements that this method needs ✨ It also describes an option set. That option set lets HPR nodes use IP networks without having to predefine link connections, by using the APPN connection network model 🦋
(R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of the IBM Corporation. 💼
1.1 Requirements 🎯
These are the requirements for the architecture specified in this memo:
- Facilitate APPN product interoperation in IP networks by documenting agreements such as the choice of the logical link control (LLC).
- Reduce system definition (e.g., by extending the connection network model to IP networks) -- Connection network support is an optional function.
- 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.
- Allow customers the flexibility to design their networks for low cost and high performance. 💸
- 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 APPN nodes can support, along 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 carry 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 does all of this end-to-end, it removes the need for these functions at 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) lets customers use APPN/HPR features like 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 uses 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 that uses IP to transport messages between nodes. UDP can tell apart multiple destinations within a given node, and it allows port-number-based prioritization in the IP network 🎀 UDP also detects corrupted packets, which HPR requires. Higher-layer protocols such as HPR are responsible for handling message loss, duplication, delay, out-of-order delivery, and loss of connectivity. UDP is enough here because HPR uses RTP for end-to-end error recovery and in-order delivery, and LDLC detects loss of connectivity as well 🫶 TCP was not chosen for the native IP DLC, because the extra services TCP provides, like error recovery, aren't needed. Also, ending TCP connections would need extra node resources (control blocks, buffers, timers, and retransmit queues), which would 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 means 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, and the zero setting is not used either 🙈 IANA has registered port numbers 12000 through 12004 for use in these two fields by the native IP DLC. Using these port numbers allows prioritization in the IP network ✨ For more details on how these fields are used, see 2.6.1, "IP Prioritization" on page 28.
The UDP Checksum is a 16-bit optional field that covers the UDP header and the user data. It also covers a pseudo-header that contains the source and destination IP addresses. The UDP checksum is used to guarantee that the data arrived intact at the intended receiver 🔍 When the UDP checksum is set to zero, it means the checksum was not calculated and should not be checked by the receiver. Use of the checksum is recommended for 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 it performs the routing function (i.e., choosing the path over which data will be sent) 🗺️ IP also describes 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 has two defined fields. The 3-bit precedence field lets senders indicate the priority of each datagram. The 4-bit type of service field indicates how the network should trade off 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 means the higher-layer protocol is UDP 🌈
2.2 Node Structure
Okay bestie, check out Figure 1 on page 6 🎀. It shows one possible node breakdown for moving HPR traffic across an IP network 🌸. Platforms can vary depending on their characteristics, so yours might look a little different 💅.
The native IP DLC has a DLC manager, one LDLC component per link, and a link demultiplexor 🧚. Since UDP is connectionless, HPR doesn't need to activate or deactivate lower-level connections. No cap, that's so chill 🫶.
The DLC manager activates and deactivates a link demultiplexor for each port, plus an instance of LDLC for each link set up on the IP network 🦋. You can have multiple links between one pair of IP addresses (like one defined link and one dynamic link for connection network traffic) 💜. Each link is identified by the source and destination IP addresses in the IP header, and by the source and destination service access point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0, "Appendix - Packet Format" on page 37) ✨. The link demultiplexor uses these identifiers to send each incoming packet to the correct LDLC instance 👑. Also, the IP address pair tied to an active link, as used in the IP header, may not change 🙈.
LDLC does more than that too. For example, it provides reliable delivery of Exchange Identification [XID] commands 🌈. Error recovery for HPR RTP packets is handled by the protocols running between the RTP endpoints 💖.
The network control layer (NCL) reads the automatic network routing (ANR) information in the HPR network header. Based on that, it passes incoming packets either up to RTP or out to an outgoing link 🔥.
Everything in the figure is drawn as a single entity, but here's how many logical instances of each there are:
- DLC manager -- 1 per node
- LDLC -- 1 per link
- Link demultiplexor -- 1 per port
- NCL -- 1 per node (or 1 per port for efficiency)
- RTP -- 1 per RTP connection
- UDP -- 1 per port
- IP -- 1 per port
Products are free to build other structures 🦋. If you do, you'll need to make the matching changes to the algorithms and protocol boundaries described in this document 🧚.
--------------------------------------------------------------------
-*
*-------------* *-------* |
|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 Structure2.3 Logical Link Control (LLC) Used for IP
Logical Data Link Control (LDLC) is what the native IP DLC uses 🎀. LDLC is defined in [2] 📚. It runs on a subset of the services from IEEE 802.2 LLC type 2 (LLC2), and it only uses the TEST, XID, DISC, DM, and UI frames 💅.
LDLC was designed to be used together with HPR (with the HPR Control Flows over RTP option set 1402) over reliable links that don't need link-level error recovery 🫶. Most frame loss in IP networks (and in the underlying frame networks) comes from congestion, not from problems with the facilities 🌊. When LDLC runs on a link, there is no link-level error recovery available. So the native IP DLC only supports RTP traffic 😭. Using LDLC also gets rid of the need for LLC2 and its costs, like adapter storage and longer path length 💜.
2.3.1 LDLC Liveness
LDLC liveness (using the LDLC TEST command and response) is REQUIRED when the underlying subnetwork doesn't tell you about connection outages 🙈. UDP is connectionless, so it can't give you outage notification. That means LDLC liveness is REQUIRED for HPR/IP links 💀.
Liveness SHOULD be sent periodically on active links, except as described in the next subsection when the option to reduce liveness traffic is implemented 🦋. The default liveness timer period is 10 seconds ⏰. When you use the defaults for the liveness timer and the retry timer (15 seconds), the gap between liveness tests is smaller than the time it takes to detect a failure (retry count multiplied by retry timer period). It may also be smaller than the time liveness needs to finish successfully (roughly the round-trip delay) 😬. This isn't a problem when liveness works the way the LDLC finite-state machine describes (see [2]) 🧚. Here's how it goes: the liveness timer belongs to a single link. It starts when the link is first activated, and again each time a liveness test completes successfully ✨. When the timer expires, a liveness test runs. When the link is operational, the gap between liveness tests is roughly the liveness timer period plus the round-trip delay 👑.
For each implementation, you need to check whether the liveness protocol works well with the default liveness and retry timer settings 🔥. For example, if the liveness timer restarts right when it expires, a different default for the liveness timer SHOULD be used 🌸.
2.3.1.1 Option to Reduce Liveness Traffic
Sometimes it's helpful to cut down on liveness traffic when the link is otherwise idle 🍓. (For example, this could let the underlying facilities be temporarily turned off when they aren't needed 🌙.) As an option, implementations MAY choose not to send liveness when the link is idle, meaning no data was sent or received over the link while the liveness timer was running 💅. (If the implementation can't tell whether data has been received, liveness testing may be stopped while no data is being sent 🫶.) Keep in mind that the RTP connections have their own liveness mechanism, which will generate traffic 🎀. Some RTP implementations let you set a large value for the ALIVE timer, which cuts down on RTP liveness traffic 💖.
If LDLC liveness is turned off while the link is idle, one side of the link may notice a link failure way earlier than the other side does 😭. That can cause these problems:
- If a node that knows about a link failure tries to reactivate the link, the partner node (which doesn't know about the failure) may reject the activation as an unsupported parallel link between the two ports 🙅.
- If a node that doesn't know about an earlier link failure sends data (including new session activations) over the link, a node that detected the earlier failure and deactivated the link may discard it 💀. As a result, session activations would fail 😩.
The mechanisms described below can fix these problems 🧚. They are only needed in a node that doesn't send liveness when the link is idle, so a node that doesn't use this option, but happens to be next to one that does, isn't REQUIRED to have them 🌈.
- (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.) Any time 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 uses a different SAP pair 🔥. So if the activation wasn't for a parallel link and was really a reactivation because one of those active links had failed, the failed link gets 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 do this is for LDLC, upon receiving an activation XID, to run liveness on all active links that have a matching IP address pair and a different SAP pair ✨.
- (Mandatory) Any time 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 let it be reestablished 🦋. A timer is REQUIRED to keep stray XIDs from deactivating an active link ⏰.
- (RECOMMENDED) A node SHOULD attempt to reactivate an HPR/IP link before acting on an LDLC-detected failure 🌷. This helps prevent session activation failures in situations where the other side detected a link failure earlier, but the network has since recovered 🫶🌈.
2.4. IP Port Activation 🎀
okay so the node operator (NO) is the one who creates a native IP DLC 💅 They do it by sending DEFINE_DLC(RQ) (with the customer-configured parameters in it) and START_DLC(RQ) commands to the node operator facility (NOF). NOF then passes those DEFINE_DLC(RQ) and START_DLC(RQ) signals along to configuration services (CS), and CS is the one that creates the DLC manager ✨ After that, the node operator can define a port by sending DEFINE_PORT(RQ) (also with customer-configured parameters) to NOF, and NOF passes the associated signal to CS 🦋
A node with adapters attached to multiple IP subnetworks can represent those multiple adapters as a single HPR/IP port. BUT (and this is a big but 😭) 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 ActivationThe following parameters are received in DEFINE_PORT(RQ) 🌸
Port nameDLC namePort type: if IP connection networks are supported, set this to shared access transport facility [SATF]. Otherwise, set it toswitched.Link station role: set tonegotiable.Maximum receive BTU size: the default is1461(that's1492less an allowance for the IP, UDP, and LLC headers) 🍓Maximum send BTU size: the default is1461(that's1492less an allowance for the IP, UDP, and LLC headers) 🍓Link activation limits(total, inbound, and outbound)IPv4 supported: set toyes.The local IPv4 address: required if IPv4 is supported.IPv6 supported: set tono. It may be set toyesin the future; see 2.9, "IPv4-to-IPv6 Migration" on page 35 🧚The local IPv6 address: required if IPv6 is supported.Retry count for LDLC: the default is3.Retry timer period for LDLC: the default is15seconds. A smaller value such as10seconds can be used for a campus network 🌈LDLC liveness timer period: the default is10seconds; see 2.3.1, "LDLC Liveness" on page 7 💜IP precedence: the setting of the 3-bit field within the Type of Service byte of the IP header, used 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 28 ✨
2.4.1. Maximum BTU Sizes for HPR/IP ⭐
okay this one is kind of a big deal 👑 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. That lines up with the typical IP maximum transmission unit (MTU) size of 1492 bytes supported by routers on token-ring networks. So 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, so 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 won't be able to control the setting of the bit that allows fragmentation. In that case, fragmentation will most likely be allowed. Fragmentation is slow and prevents prioritization based on UDP port numbers, but it does allow connectivity across paths with small MTU sizes. So it's a tradeoff, bestie 🦋
2.5. IP Transmission Groups (TGs) 🌸
2.5.1. Regular TGs 🎀
Okay bestie, regular HPR TGs can be set up in IP networks using the native IP DLC architecture 💖 Each TG is made 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 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 tied to a single IP address), an incoming packet can be mapped to its link using the IP address pair and the service access point (SAP) address pair 🦋 If a node gets an activation XID for a defined link whose IP address pair and SAP pair match an active defined link, that node can assume the link has failed and the partner node is reactivating it. In that case, as an optimization, the node receiving the XID can take down the active link and let it be reestablished in the IP network. Because UDP packets can arrive out of order, this optimization needs a timer so a stray XID can't deactivate a working link 🙈
Support for multiple defined links between a pair of HPR/IP ports is OPTIONAL. Right now there's no value in defining multiple HPR/IP links between a pair of ports. Later, if HPR/IP support for the Resource ReSerVation Protocol (RSVP) [10] gets defined, it MAY be advantageous to define parallel links so traffic can be split by COS across RSVP "sessions" 🌈 With RSVP, HPR would be able to reserve bandwidth in IP networks. An HPR logical link would map 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 gets mapped to the defined link station (if one exists) tied to 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 tied to the matching defined link station. (They MAY not be the same if the adjacent node has multiple IP addresses and the configuration wasn't coordinated correctly 😭)
If parallel HPR/IP links between ports are supported, multiple defined link stations MAY be tied to 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. But since the same TG characteristics MAY be used for all HPR/IP links between a given pair of ports, all the link stations tied to the port in the adjacent node SHOULD be equivalent. As a result, TG number negotiation using negotiable TG numbers MAY be used 🧚
Later on, if multiple HPR/IP links with different characteristics get defined between a pair of ports using RSVP, defined link stations will need enough configured info to be matched with incoming XIDs. (Matching an incoming XID to the right defined link station lets CS give the correct TG characteristics to topology and routing services (TRS).) At that point CS will do the mapping based on both the IP address of the adjacent node and a predefined TG number 👑
The node starting link activation knows which link it's activating. Some parameters sent in prenegotiation XID are defined in the regular link station configuration and aren't allowed to change in later 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, so it can set the parameters that can't change. So 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 🫶 Also, the node receiving the first XID will force the node activating the link to send the first prenegotiation XID by answering 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 how many null XIDs it will send. Once that limit is reached, the 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 an unexpected null XID. If the node that received the first XID gets 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 🍓
- The destination IP host name (this parameter can usually be mapped to the destination IP address): If the link isn't 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 so an incoming link activation can 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), the link activation can't be matched with the link station definition, and the default parameters specified in the local port definition will be used.
- 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 can't be determined using the destination IP host name.)
- The destination IP address (in the format specified by the destination IP version; this parameter is only REQUIRED if the address can't be determined using the destination IP host name.)
- 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)
- Destination service access point address (DSAP) used for XID, TEST, DISC, and DM (default is X'04')
- 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.)
- Maximum receive BTU size (default is 1461; this parameter is used to override the setting in DEFINE_PORT.)
- Maximum send BTU size (default is 1461; this parameter is used to override the setting in DEFINE_PORT.)
- 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 28; this parameter is used to override the settings in DEFINE_PORT)
- Shareable with connection network traffic (default is yes for non-RSVP links)
- Retry count for LDLC (default is 3; this parameter is used to override the setting in DEFINE_PORT)
- 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)
- LDLC liveness timer period (default is 10 seconds; this parameter is to override the setting in DEFINE_PORT; see 2.3.1, "LDLC ness" on page 7)
- Auto-activation supported (default is no; MAY be set to yes when the local node has switched access to the IP network)
- Limited resource (default is to set in concert with auto-activation supported)
- Limited resource liveness timer (default is 45 sec.)
- Port name
- Adjacent CP name (OPTIONAL)
- Local CP-CP sessions supported
- Defined TG number (OPTIONAL)
- 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|2.5.1.1. Limited Resources and Auto-Activation ✨
*------------------------------------------------------------------*
. . . .
. 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)Okay so in Figure 4, when an XID shows up for a brand new link, it gets passed to the DLC manager 📬. The DLC manager sends CONNECT_IN(RQ) to tell CS about the incoming link activation, and CS replies with CONNECT_IN(+RSP) to say yes, come in 💅. Then the DLC manager creates a new LDLC instance 🦋, informs the link demultiplexor, and forwards the XID to CS via LDLC. CS responds by sending an XID back to the adjacent node. Main character energy, honestly 👑.
The next two 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, once CS gets STOP_LS(RQ) from NOF, it sends DEACT to let the partner node know the HPR link is getting deactivated 🥀. When that response comes back, CS sends DISCONNECT(RQ) to the DLC manager, and the DLC manager deactivates the LDLC instance. Then, when DISCONNECT(RSP) arrives, CS sends STOP_LS(RSP) back to NOF. Clean exit, no drama 💖.
*------------------------------------------------------------------*
|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 gets a DISC 🫣. CS sends STOP_LS(IND) to NOF. Here's the tea: IP is connectionless, so the DLC manager has no clue the link went down 🙈. That's why CS also has to send DISCONNECT(RQ) to the DLC manager, which then deactivates the LDLC instance. Gotta keep everybody in the loop, periodt 🧚.
2.5.1.1. Limited Resources and Auto-Activation ✨
Okay, so to keep tariff charges low 💸, the APPN architecture lets you define switched links as limited resources. A limited-resource link gets deactivated when no sessions are using it. Intermediate HPR nodes can't see the LU-LU sessions (logical unit to logical unit sessions) riding inside crossing RTP connections, so in HPR nodes, limited-resource TGs get deactivated once no traffic has been detected for some period of time ⏳. APPN links can also be defined as auto-activatable 🔥. Auto-activatable links come alive the moment a new session gets routed across them. Iconic ✨.
An HPR node might have access to an IP network through a switched access link 🌈. In that kind of setup, it can be a good idea for customers to define regular HPR/IP links as limited resources AND as auto-activatable 💅.
2.5.2. IP Connection Networks 🦋
Connection network support for IP networks (option set 2010) is covered in this section 🎀.
APPN architecture defines single link TGs across the point-to-point lines that connect APPN nodes 🧵. The obvious extension would be a TG between every pair of nodes attached to a shared access transport facility (SATF), like a LAN or an IP network. BUT the system definition for a whole mesh of TGs like that is wildly expensive 😭, so it's basically prohibitive for any network with more than a few nodes. That's why the APPN connection network model was invented: to cut down on the system definition needed to set up TGs between APPN nodes 🫶.
Other TGs can be defined through the SATF too, as long as they aren't part of the connection network 🌸. These are called regular TGs in this document. They're required for sessions between control points (CP-CP sessions), but they can also carry LU-LU sessions.
In the connection network model, a virtual routing node (VRN) represents the SATF 🧚. Each node attached to the SATF defines one single TG to the VRN, instead of a TG to every other attached node. Much less to set up, bestie 💖.
Topology and routing services (TRS) decides that a session gets routed between two nodes across a connection network by putting the connection network TGs between each of those nodes and the VRN into the Route Selection control vector (RSCV) 🗺️. When a network node has a TG to a VRN, the network topology info for that TG includes the DLC signaling info needed to reach that node across the SATF. For an end node, the DLC signaling info comes back as part of the normal directory services (DS) process. TRS includes the DLC signaling info for TGs across connection networks inside RSCVs 👑.
CS creates a dynamic link station in two situations: when the next hop in the RSCV of an ACTIVATE_ROUTE signal (from session services, SS) is a connection network TG, or when an adjacent node starts link activation after getting such an ACTIVATE_ROUTE signal 🔥. Dynamic link stations are normally treated as limited resources, so they get deactivated when no sessions are using them 💀. CP-CP sessions aren't supported on connections that use dynamic link stations, because CP-CP sessions usually need to stay up nonstop 🙈.
Setting up a link across a connection network normally means using CP-CP sessions to figure out the destination IP address 🔍. And since CP-CP sessions have to flow across regular TGs, defining a connection network doesn't get rid of the need to define regular TGs too. Not me having to define both, but here we are 😭.
Normally, you define one connection network per LAN (so one VRN per LAN) 🌿. For an environment with several interconnected campus IP networks, a single wide-area connection network can be defined. On top of that, separate connection networks can be defined between the nodes connected to each campus IP network 🌈✨.
2.5.2.1 Establishing IP Connection Networks ✨
Okay bestie, once the port is defined, you can define a connection network on it 💖 To support multiple TGs from one port to a VRN, you do it in this order:
- First, the connection network and its VRN get defined on the port 🎀. The node operator issues
DEFINE_CONNECTION_NETWORK(RQ)to NOF, and NOF passesDEFINE_CN(RQ)over to CS. - Then each TG from the port to the VRN gets defined 🦋. The node operator issues
DEFINE_CONNECTION_NETWORK_TG(RQ)to NOF, and NOF passesDEFINE_CN_TG(RQ)to CS.
Before Resource ReSerVation Protocol (RSVP) support existed, you only needed one connection network TG between a port and a VRN 🌸. In that case, product support for DEFINE_CN_TG(RQ) isn't required, because one set of port configuration parameters for each connection network is enough. If a NOF implementation doesn't support DEFINE_CN_TG(RQ), the parameters listed below for DEFINE_CN_TG(RQ) get supplied by DEFINE_CN(RQ) instead 🧚. Also, the Connection Network TG Numbers (X'81') subfield in the TG Descriptor (X'46') control vector on an activation XID is only needed to support multiple connection network TGs to a VRN, and using it 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
Now the tricky bit 👀. An incoming dynamic link activation can get rejected with sense data X'10160046' if there's already a dynamic link between the two ports over the same connection network (meaning the same VRN CP name) 🙅♀️. If a node gets an activation XID for a dynamic link whose IP address pair, SAP pair, and VRN CP name all match an active dynamic link, that node can assume the link has failed and the partner is reactivating it 🔥. In that case, as an optimization, the node receiving the XID can tear down the active link and let it get reestablished over the IP network. Since UDP packets can arrive out of order, this optimization needs a timer so a stray XID can't deactivate an active link ⏰. Iconic protection, honestly 🫶.
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. When CS gets ACTIVATE_PORT(RSP) back from the DLC manager, it sends a TG_UPDATE signal to TRS for each defined connection network TG. Each signal tells TRS that a TG to the VRN is activated, and includes TG vectors describing that TG 💜. If the port fails or gets deactivated, CS sends TG_UPDATE saying the connection network TGs aren't operational anymore 😭. TGs between a network node and the VRN live in the network topology database, while TGs between an end node and the VRN only live in the local topology database 🌈. If TRS doesn't have a node entry for the VRN in its topology database, TRS creates one on its own. A VRN node entry only becomes part of the network topology database if a network node has defined a TG to the VRN 🍓. Even so, TRS can still pick a direct path between two end nodes across a connection network without a VRN node entry, which is giving flexibility ✨.
*--------------------------------------------------------------------*
| 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 carry the following information 🎀:
- TG number
- VRN CP name
- TG characteristics used during route selection
- Effective capacity
- Cost per connect time
- Cost per byte transmitted
- Security
- Propagation delay
- User defined parameters
- 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, CS figures out the parameters using several inputs 🧠. Parameters specific to the local port, connection network, or TG are system defined and come in through DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ). The signaling info for the destination node, including its IP address, comes in with the ACTIVATE_ROUTE request from SS 💅.
These configuration parameters come in through DEFINE_CN(RQ) 💖:
- Connection network name (CP name of the VRN)
- Limited resource liveness timer (default is 45 sec.)
- 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 28; this parameter is used to override the settings in DEFINE_PORT)
These configuration parameters come in through DEFINE_CN_TG(RQ) 🌈:
- Port name
- Connection network name (CP name of the VRN)
- Connection network TG number (set to a value between 1 and 239)
- TG characteristics (see 2.6.3, "Default TG Characteristics" on page 30)
- Link service access point address (LSAP) used for XID, TEST, DISC, and DM (default is X'04')
- Link service access point address (LSAP) used for HPR network layer packets (default is X'C8')
- Limited resource (default is yes)
- Retry count for LDLC (default is 3; this parameter is used to override the setting in DEFINE_PORT)
- 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)
- 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)
- Shareable with other HPR traffic (default is yes for non-RSVP links)
- Maximum receive BTU size (default is 1461; this parameter is used to override the value in DEFINE_PORT(RQ).)
- Maximum send BTU size (default is 1461; this parameter is used to override the value in DEFINE_PORT(RQ).)
These parameters come in through ACTIVATE_ROUTE for connection network TGs 👑:
- The TG pair
- 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'.)
- The destination IP address (in the format specified by the destination IP version)
- Destination service access point address (DSAP) used for XID, TEST, DISC, and DM
2.5.2.3 Sharing of TGs 🤝
Connection network traffic gets multiplexed onto a regular defined IP TG (usually the one used for CP-CP session traffic) to cut down on control block storage 🪄. No XIDs flow to set up a new TG on the IP network, and no new LLC gets created. When a regular TG is shared, incoming traffic gets demultiplexed the normal way. If the regular TG gets deactivated, a path switch is required for the HPR connection network traffic sharing it 😱.
Multiplexing is possible if these conditions hold 💜:
- Both the regular TG and the connection network TG to the VRN are defined as shareable between HPR traffic streams.
- The destination IP address is the same.
- The regular TG is established first. (Because links established for connection network traffic don't support CP-CP sessions, there's little value in letting a regular TG share one of those links 🙃.)
The destination node gets notified via XID when a TG can be shared between HPR data streams 📣. On either end, when CS receives ACTIVATE_ROUTE requesting a shared TG for connection network traffic, it checks its TGs for one that meets the required specs before starting a new link 🔍. First, CS looks for a link already established for the TG pair. If there isn't one, CS checks whether there's a regular TG that can be shared and, if there are several, picks which one to use 💅. The result is that RTP connections routed over the same TG pair might actually use different links, and RTP connections routed over different TG pairs might use the same link 🌸. Chaotic, but make it make sense 💀.
2.5.2.4 Minimizing RSCV Length ✨
okay so the Route Selection (X'2B') control vector, aka the RSCV, maxes out at 255 bytes 💅 and connection networks make it way chunkier 😭. Why? One SATF hop needs two connection network TGs, so you need two TG Descriptor (X'46') control vectors, and stuffing DLC signaling info into those makes them longer too 🙈. Net result: fewer hops fit in an RSCV that crosses a connection network. Not ideal, bestie.
So the big goal when designing the IP signaling formats is keeping them tiny 🤏. There are also some extra tricks to dodge the RSCV length limit.
Here's one: for an IP connection network, DLC signaling info is only needed for the second TG (the one from the VRN to the destination node). The first TG's signaling info is defined locally at the origin node, so the topology database leaves DLC signaling info out of the entry for a connection network TG going from a network node to a VRN. That info lives in the allied entry for the TG in the opposite direction 🦋. This trick can't be used for a connection network TG between a VRN and an end node, though. And a node implementing IP connection networks doesn't include IP signaling info for the first connection network TG when it builds an RSCV, so the vibe is "skip the redundant stuff" 💖.
Next, picture APPN network nodes routing between legacy LANs and wide-area IP networks. In that setup, it is recommended that customers not define connection network TGs between those network nodes and the VRNs that stand in for the legacy LANs 🌸. Usually there are defined links between the end nodes on the legacy LANs and the network nodes that act as network node servers for them. Those defined links can carry user traffic as well as control traffic, and using them cuts down the number of connection network hops in RSCVs between end nodes on different legacy LANs ✨.
And finally, if RSCVs still can't fit enough hops, extended border nodes (EBNs) can partition the network 👑. The EBNs then handle piecewise subnet route calculation and RSCV swapping, so the whole route never has to be described in one RSCV with its length limit. Iconic problem-solving, honestly 🔥.
2.5.3 XID Changes
okay this one is a whole saga 🎀. IP networks lose packets or deliver them out of order way more often than other "link" technologies do 😬. Because of that, a problem with the XID3 negotiation protocol got exposed.
Here's how it goes wrong. Node A sends XID3 (np, NEG), Node B answers with XID3 (np, SEC), and Node A's XID3 (np, PRI) response gets lost. Node A times out and resends XID3 (np, SEC) as a link-level command. Node B sees that and thinks, "oh cool, Node A got my XID3 (np, PRI) and we're done with activation XID exchange!" So Node B sends a SETMODE (SNRM, SABME, or XID_DONE_RQ, depending on the link type). When Node A gets that SETMODE, it fails the link activation, because it never got an XID3 (np, PRI) from Node B confirming Node B really does agree to be the primary. Ugh. And there are similar issues with incomplete TG number negotiation too 🙃.
--------------------------------------------------------------------
*---------------------------------*
|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
To fix the incomplete role and TG number negotiation, two new indicators get defined in XID3 💜. Heads up: the fix only works if both link stations support these new indicators.
- Negotiation Complete Supported indicator (byte 12 bit 0): this 1-bit field says whether the Negotiation Complete indicator is supported. It's only meaningful when the XID exchange state is negotiation proceeding, and it's reserved otherwise. A value of 0 means the Negotiation Complete indicator isn't supported, and a value of 1 means it is.
- Negotiation Complete indicator (byte 12 bit 1): this 1-bit field only matters 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 it's reserved. A secondary link station that supports enhanced XID negotiation sets it to 1 once it considers activation XID negotiation complete for both link station role and TG number. In other words, it's 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, it knows it can safely send SETMODE, as long as it also considers XID negotiation complete. Here's how the new indicators flow when both 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
So in flow 4, Node B notices that Node A doesn't think XID negotiation is complete yet. Node B resends its current XID info in flow 5 💅. When Node A gets that, it replies in flow 6 with an XID saying negotiation is complete. Now Node B, acting as the primary link station, sends SETMODE, and the link activates successfully 🎉.
There are also migration cases where only one link station supports enhanced XID negotiation. 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
This negotiation fails because Node B doesn't understand the new indicators, so it just responds to flow 4 with SETMODE 🙈.
In the next sequence, Node B supports the new indicators but Node A doesn't 🌈.
--------------------------------------------------------------------
*---------------------------------*
|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
This one fails too. Node A doesn't understand the new indicators, so it can't say in flow 4 that it thinks XID negotiation isn't complete. Node B figures out that the secondary link station (Node A) doesn't support the new indicators, so it responds 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 can fail for a bunch of different reasons, bestie 🥺. When activation over a connection network, or of an auto-activatable link, is attempted after ACTIVATE_ROUTE comes in from SS, the failure gets reported with ACTIVATE_ROUTE_RSP, and that response carries sense data explaining what went wrong. For other regular defined links, the failure is reported with START_LS(RSP) containing sense data instead 💜.
Just like with any session activation failure, the sense data also goes to the node that started the session 🎀. At the APPN-to-HPR boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data control vector gets generated and returned to the primary logical unit (PLU).
At an intermediate HPR node, a link activation failure can be reported with sense data X'08010000' or X'80020000'. At a node with route-selection responsibility, the 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 🚦
okay so, typically IP routers just process packets first-come-first-served, which means no packet gets to cut the line 💅 but some routers are a little more picky and prioritize packets based on IP precedence (that 3-bit field inside the Type of Service byte of the IP header) or UDP port numbers. 🙈 ngl there's a catch: with the current plans for IP security, the UDP port numbers are encrypted, so routers literally can't prioritize encrypted traffic based on them 💀 BUT HPR is going to be able to exploit routers that have a priority function, so it's still giving main character energy 🦋
the IANA has assigned 5 UDP port numbers, 12000-12004 (decimal) 🎀 four of them are for ANR-routed network layer packets (NLPs) and match the APPN transmission priorities: network is 12001, high is 12002, medium is 12003, and low is 12004. 🍓 then port 12000 handles a set of LLC commands (XID, TEST, DISC, and DM) plus the function-routed NLPs (XID_DONE_RQ and XID_DONE_RSP). these ports are used for "listening" and also show up as the destination port number in the UDP header of outgoing packets. the source port number in that UDP header can be set to one of these same ports OR to an ephemeral port number, so you've got options bestie 🌈
the IP precedence for each transmission priority, and for the LLC command set (including function-routed NLPs), is configurable ⚙️ the vibe here is that precedence is meant to tie into priority queueing, NOT bandwidth allocation. however, you can still administer bandwidth allocation policies by matching on the precedence field, which is lowkey so clever 🧠 here's the default mapping, in the table below 👇
+---------------------------------------------+
| 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 of how this mapping could play out, telnet, interactive ftp, and business-use web traffic could get a precedence value of 011, and batch ftp could get 000 😭 these settings were based on the AIW's understanding of what IP precedence is meant for, so if the IETF ever standardizes its use differently, the use of IP precedence will be adjusted to match 🫶 also, the other fields in the IP TOS byte aren't used and should be set to 0 💜
for outgoing ANR-routed NLPs, the destination UDP port (and optionally the source one) and the IP precedence get set based on the transmission priority that's specified in the HPR network header 🔥
the vibe is that this native IP DLC architecture is mostly for private campus or wide-area intranets 🏫 where the customer can configure the routers to honor the transmission priority tied to the UDP port numbers or IP precedence. it can route HPR traffic over the Internet too, but ✨ heads up ✨ routers over there don't currently provide the priority function, so customers may find the performance unacceptable 😬
in the future, bandwidth reservation might be possible in IP networks through the Resource ReSerVation Protocol (RSVP), or through the differentiated services that the Integrated Services working group of the IETF is currently studying 🔮 if that happens, bandwidth could be reserved for an HPR/IP link, which would insulate HPR traffic from congestion caused by other protocols' traffic 🛡️✨
2.6.2. APPN Transmission Priority and COS 🏎️
okay this section is so satisfying. APPN transmission priority and class of service (COS) let APPN TGs be highly utilized with batch traffic WITHOUT wrecking the performance of response-time-sensitive interactive traffic 🤯 and scheduling algorithms make sure lower-priority traffic isn't completely blocked, so nobody gets left on read 💀 the result is predictable performance, which is iconic 👑
when a session starts across an APPN network, the session's mode gets mapped into a COS and a transmission priority 🎀 each COS has a COS table that route selection uses to pick the most appropriate TGs (based on their TG characteristics) for the session to traverse. the TG characteristics and COS tables are set up so that APPN topology and routing services (TRS) will pick the right TG for the traffic of each COS. it's literally a perfectly matched system, periodt 💅🦋
2.6.3 Default TG Characteristics ✨
okay so Chapter 7 (TRS) of [1] has a whole set of SNA-defined TG default profiles 💅 when a TG (connection network or regular) gets defined as a particular technology, like ethernet or X.25, but nobody specified its characteristics, the technology's default profile gets used in the TG's topology entry 🧚 the customer is totally free to override these values via configuration 🫶. some technologies have more than one profile (ISDN has one for switched and one for nonswitched, iykyk) 🌸. two default profiles are REQUIRED for IP TGs 💖 because there are both campus and wide-area IP networks, so two vibes are needed. for each HPR/IP TG, the 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 "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's 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 🌈:
- to ensure that the tables assign reasonable weights to ATM TGs relative to each other and other technologies based on cost, speed, and delay 💰
- 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 Linksotherwise, 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
okay bestie, so APPN and HPR management info is already covered by two MIBs: the APPN MIB (RFC 2155 [11]) and the HPR MIB (RFC 2238 [13]) 📊✨. On top of that, the SNANAU working group of the IETF plans to define an HPR-IP-MIB for HPR/IP-specific info 🎀. This one is giving main character energy because it will map APPN traffic types to IP Type of Service Precedence values, and it will also count the UDP packets sent for each traffic type 💅.
there are also rules that must be specified about the values an HPR/IP implementation returns for objects in the APPN MIB 👀:
- 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:
appnPortDlcTypeappnLsDlcTypeappnLsStatusDlcType
- Link-level addresses are reported in the following objects:
appnPortDlcLocalAddrappnLsLocalAddrappnLsRemoteAddrappnLsStatusLocalAddrappnLsStatusRemoteAddr
All of these objects should return ASCII character strings that represent IP addresses in the usual dotted-decimal format. (Honestly it's not clear yet what the "usual...format" will be for IPv6 addresses 🙈, but whatever it turns out to be, that's what these objects will return when an HPR/IP link traverses an IP network 🌈.)
- The following two objects return Object Identifiers that tie table entries in the APPN MIB to entries in lower-layer MIBs:
appnPortSpecificappnLsSpecific
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 (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 only interoperate if both ends use the same version of the IP protocol 🤝. Most IPv6 implementations (routers and hosts) will actually have dual IPv4/IPv6 stacks, though 💖. IPv4 and IPv6 traffic can share transmission facilities as long as the router/host at each end has a dual stack, so they'll coexist on the same infrastructure in most areas 🦋. The version number in the IP header is what maps incoming packets to either the IPv4 or IPv6 stack. A dual-stack host that wants to talk to an IPv4 host will use IPv4 💅.
Hosts that have an IPv4 address can use it as an IPv6 address by using a special IPv6 address prefix (i.e., it is an embedded IPv4 address) 🧚. This mapping was mainly provided for "legacy" application compatibility, because those applications don't have the socket structures needed to store full IPv6 addresses 😭. Two IPv6 hosts may communicate using IPv6 with embedded-IPv4 addresses too.
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 like this:
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 like this: 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 DNS provides an IPv6 address, that one 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. That means 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", STD 6, RFC 768, August 1980.
[7] Postel, J., "Internet Protocol", STD 5, 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", STD 3, RFC 1122, October 1989.
[10] Braden, R., Zhang, L., Berson, S., Herzog, S., 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.
[13] Clouston, B., and B. Moore, "Definitions of Managed Objects for HPR using SMIv2", RFC 2238, November 1997.
4.0 Security Considerations
okay, security time, and this part is serious bestie 🔒😭. For HPR, the IP network appears to be a link. Because of that, the SNA session-level security functions (user authentication, LU authentication, session encryption, etc.) are still available for use ✨. On top of that, HPR traffic flows as UDP datagrams through the IP network, so IPsec can be used to provide network-layer security inside the IP network 🛡️.
There are firewall considerations when you support 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, and the source port number is not relevant. That means 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, there's a possibility of 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. no cap, that's a big deal 🚨.
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.com6.0 Appendix - Packet Format
okay last stop on this part, the packet formats 📦🎀. These are the actual bytes on the wire, so the layout is everything 💅.
6.1 HPR Use of IP Formats
6.1.1 IP Format for LLC Commands and Responses
the formats described here are the ones used for the LLC commands and responses. That's XID command and response, TEST command and response, DISC command, and DM response 🌸.
+----------------------------------------------------------------------+
| 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 RFC 791. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | Note 2: Rules for encoding the UDP header can be |
| | | found in RFC 768. |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+Okay so the LLC header note is the one that points you to ISO/IEC 8802-2:1994 (also known as ANSI/IEEE Std 802.2, 1994 Edition) for the rules on encoding it. Bestie, that's where the full LLC details live 📚✨
6.1.2. IP Format for NLPs in UI Frames
Ngl this is the part where the IP format for NLPs gets its moment 🦋 It's used for either LDLC specific messages or HPR session and control traffic. Let's peek at the box first 👀
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+The notes are where the references hang out 💅 Note 1 sends you to RFC 791 for the IP header rules, and Note 2 sends you to RFC 768 for the UDP header rules. Iconic citations, honestly 🌸
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+Bestie, Notes 3 and 4 are the bit-level tea 🫖 The User-Defined Address bit counts as part of the DSAP in Note 3, and the Individual/Group bit in the DSAP is set to 0 by the sender and ignored by the receiver. In Note 4 the User-Defined Address bit counts as part of the SSAP, and the Command/Response bit in the SSAP is set to 0 by the sender and ignored by the receiver. Main character details 👑
7.0 Full Copyright Statement ✨
Okay, legal section time, but make it cute 🎀 The copyright belongs to the Internet Society, and the year is Copyright (C) The Internet Society (1997). All Rights Reserved. 💜
So here's the deal. This document, and translations of it, can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can be written, copied, published and distributed, in whole or in part, with no restrictions of any kind 🦋 The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🫶
Also, the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙈 The exceptions are when it's needed to develop Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or when it's translated into languages other than English 🌈
The limited permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them ✨ That's a forever promise, bestie 💖
Finally, the disclaimer, which is a little serious 💀 This document and the information in it are 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 🥺 Translation: no promises about the info being perfect, so double-check before you ship anything 🫶
📦 where this page comes from
- ietf: rfc2353 1998-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms