home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2353.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  116.9 KB  |  2,692 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Dudley
  8. Request for Comments: 2353                                           IBM
  9. Category: Informational                                         May 1998
  10.  
  11.  
  12.                         APPN/HPR in IP Networks
  13.            APPN Implementers' Workshop Closed Pages Document
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  24.  
  25. Table of Contents
  26.  
  27.    1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
  28.    1.1  Requirements  . . . . . . . . . . . . . . . . . . . . . . .   3
  29.    2.0  IP as a Data Link Control (DLC) for HPR   . . . . . . . . .   3
  30.    2.1  Use of UDP and IP   . . . . . . . . . . . . . . . . . . . .   4
  31.    2.2  Node Structure  . . . . . . . . . . . . . . . . . . . . . .   5
  32.    2.3  Logical Link Control (LLC) Used for IP  . . . . . . . . . .   8
  33.      2.3.1  LDLC Liveness   . . . . . . . . . . . . . . . . . . . .   8
  34.        2.3.1.1  Option to Reduce Liveness Traffic   . . . . . . . .   9
  35.    2.4  IP Port Activation  . . . . . . . . . . . . . . . . . . . .  10
  36.      2.4.1  Maximum BTU Sizes for HPR/IP  . . . . . . . . . . . . .  12
  37.    2.5  IP Transmission Groups (TGs)  . . . . . . . . . . . . . . .  12
  38.      2.5.1  Regular TGs   . . . . . . . . . . . . . . . . . . . . .  12
  39.        2.5.1.1  Limited Resources and Auto-Activation   . . . . . .  19
  40.      2.5.2  IP Connection Networks  . . . . . . . . . . . . . . . .  19
  41.        2.5.2.1  Establishing IP Connection Networks   . . . . . . .  20
  42.        2.5.2.2  IP Connection Network Parameters  . . . . . . . . .  22
  43.        2.5.2.3  Sharing of TGs  . . . . . . . . . . . . . . . . . .  24
  44.        2.5.2.4  Minimizing RSCV Length  . . . . . . . . . . . . . .  25
  45.      2.5.3  XID Changes   . . . . . . . . . . . . . . . . . . . . .  26
  46.      2.5.4  Unsuccessful IP Link Activation   . . . . . . . . . . .  30
  47.    2.6  IP Throughput Characteristics   . . . . . . . . . . . . . .  34
  48.      2.6.1  IP Prioritization   . . . . . . . . . . . . . . . . . .  34
  49.      2.6.2  APPN Transmission Priority and COS  . . . . . . . . . .  36
  50.      2.6.3  Default TG Characteristics  . . . . . . . . . . . . . .  36
  51.      2.6.4  SNA-Defined COS Tables  . . . . . . . . . . . . . . . .  38
  52.      2.6.5  Route Setup over HPR/IP links   . . . . . . . . . . . .  39
  53.      2.6.6  Access Link Queueing  . . . . . . . . . . . . . . . . .  39
  54.    2.7  Port Link Activation Limits   . . . . . . . . . . . . . . .  40
  55.  
  56.  
  57.  
  58. Dudley                       Informational                      [Page 1]
  59.  
  60. RFC 2353                APPN/HPR in IP Networks                 May 1998
  61.  
  62.  
  63.    2.8  Network Management  . . . . . . . . . . . . . . . . . . . .  40
  64.    2.9  IPv4-to-IPv6 Migration  . . . . . . . . . . . . . . . . . .  41
  65.    3.0  References  . . . . . . . . . . . . . . . . . . . . . . . .  42
  66.    4.0  Security Considerations   . . . . . . . . . . . . . . . . .  43
  67.    5.0  Author's Address  . . . . . . . . . . . . . . . . . . . . .  44
  68.    6.0  Appendix - Packet Format  . . . . . . . . . . . . . . . . .  45
  69.    6.1  HPR Use of IP Formats   . . . . . . . . . . . . . . . . . .  45
  70.      6.1.1  IP Format for LLC Commands and Responses  . . . . . . .  45
  71.      6.1.2  IP Format for NLPs in UI Frames   . . . . . . . . . . .  46
  72.    7.0  Full Copyright Statement  . . . . . . . . . . . . . . . . .  48
  73.  
  74. 1.0  Introduction
  75.  
  76.    The APPN Implementers' Workshop (AIW) is an industry-wide consortium
  77.    of networking vendors that develops Advanced Peer-to-Peer
  78.    Networking(R) (APPN(R)) standards and other standards related to
  79.    Systems Network Architecture (SNA), and facilitates high quality,
  80.    fully interoperable APPN and SNA internetworking products.  The AIW
  81.    approved Closed Pages (CP) status for the architecture in this
  82.    document on December 2, 1997, and, as a result, the architecture was
  83.    added to the AIW architecture of record.  A CP-level document is
  84.    sufficiently detailed that implementing products will be able to
  85.    interoperate; it contains a clear and complete specification of all
  86.    necessary changes to the architecture of record.  However, the AIW
  87.    has procedures by which the architecture may be modified, and the AIW
  88.    is open to suggestions from the internet community.
  89.  
  90.    The architecture for APPN nodes is specified in "Systems Network
  91.    Architecture Advanced Peer-to-Peer Networking Architecture Reference"
  92.    [1].  A set of APPN enhancements for High Performance Routing (HPR)
  93.    is specified in "Systems Network Architecture Advanced Peer-to-Peer
  94.    Networking High Performance Routing Architecture Reference, Version
  95.    3.0" [2].  The formats associated with these architectures are
  96.    specified in "Systems Network Architecture Formats" [3].  This memo
  97.    assumes the reader is familiar with these specifications.
  98.  
  99.    This memo defines a method with which HPR nodes can use IP networks
  100.    for communication, and the enhancements to APPN required by this
  101.    method.  This memo also describes an option set that allows the use
  102.    of the APPN connection network model to allow HPR nodes to use IP
  103.    networks for communication without having to predefine link
  104.    connections.
  105.  
  106.    (R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of
  107.    the IBM Corporation.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Dudley                       Informational                      [Page 2]
  115.  
  116. RFC 2353                APPN/HPR in IP Networks                 May 1998
  117.  
  118.  
  119. 1.1  Requirements
  120.  
  121.    The following are the requirements for the architecture specified in
  122.    this memo:
  123.  
  124.    1.  Facilitate APPN product interoperation in IP networks by
  125.        documenting agreements such as the choice of the logical link
  126.        control (LLC).
  127.  
  128.    2.  Reduce system definition (e.g., by extending the connection
  129.        network model to IP networks) -- Connection network support is an
  130.        optional function.
  131.  
  132.    3.  Use class of service (COS) to retain existing path selection and
  133.        transmission priority services in IP networks; extend
  134.        transmission priority function to include IP networks.
  135.  
  136.    4.  Allow customers the flexibility to design their networks for low
  137.        cost and high performance.
  138.  
  139.    5.  Use HPR functions to improve both availability and scalability
  140.        over existing integration techniques such as Data Link Switching
  141.        (DLSw) which is specified in RFC 1795 [4] and RFC 2166 [5].
  142.  
  143. 2.0  IP as a Data Link Control (DLC) for HPR
  144.  
  145.    This memo specifies the use of IP and UDP as a new DLC that can be
  146.    supported by APPN nodes with the three HPR option sets:  HPR (option
  147.    set 1400), Rapid Transport Protocol (RTP) (option set 1401), and
  148.    Control Flows over RTP (option set 1402).  Logical Data Link Control
  149.    (LDLC) Support (option set 2006) is also a prerequisite.
  150.  
  151.    RTP is a connection-oriented, full-duplex protocol designed to
  152.    transport data in high-speed networks.  HPR uses RTP connections to
  153.    transport SNA session traffic.  RTP provides reliability (i.e., error
  154.    recovery via selective retransmission), in-order delivery (i.e., a
  155.    first-in-first-out [FIFO] service provided by resequencing data that
  156.    arrives out of order), and adaptive rate-based (ARB) flow/congestion
  157.    control. Because RTP provides these functions on an end-to-end basis,
  158.    it eliminates the need for these functions on the link level along
  159.    the path of the connection.  The result is improved overall
  160.    performance for HPR.  For a more complete description of RTP, see
  161.    Appendix F of [2].
  162.  
  163.    This new DLC (referred to as the native IP DLC) allows customers to
  164.    take advantage of APPN/HPR functions such as class of service (COS)
  165.    and ARB flow/congestion control in the IP environment.  HPR links
  166.    established over the native IP DLC are referred to as HPR/IP links.
  167.  
  168.  
  169.  
  170. Dudley                       Informational                      [Page 3]
  171.  
  172. RFC 2353                APPN/HPR in IP Networks                 May 1998
  173.  
  174.  
  175.    The following sections describe in detail the considerations and
  176.    enhancements associated with the native IP DLC.
  177.  
  178. 2.1  Use of UDP and IP
  179.  
  180.    The native IP DLC will use the User Datagram Protocol (UDP) defined
  181.    in RFC 768 [6] and the Internet Protocol (IP) version 4 defined in
  182.    RFC 791 [7].
  183.  
  184.    Typically, access to UDP is provided by a sockets API.  UDP provides
  185.    an unreliable connectionless delivery service using IP to transport
  186.    messages between nodes.  UDP has the ability to distinguish among
  187.    multiple destinations within a given node, and allows port-number-
  188.    based prioritization in the IP network.  UDP provides detection of
  189.    corrupted packets, a function required by HPR.  Higher-layer
  190.    protocols such as HPR are responsible for handling problems of
  191.    message loss, duplication, delay, out-of-order delivery, and loss of
  192.    connectivity.  UDP is adequate because HPR uses RTP to provide end-
  193.    to-end error recovery and in-order delivery; in addition, LDLC
  194.    detects loss of connectivity.  The Transmission Control Protocol
  195.    (TCP) was not chosen for the native IP DLC because the additional
  196.    services provided by TCP such as error recovery are not needed.
  197.    Furthermore, the termination of TCP connections would require
  198.    additional node resources (control blocks, buffers, timers, and
  199.    retransmit queues) and would, thereby, reduce the scalability of the
  200.    design.
  201.  
  202.    The UDP header has four two-byte fields.  The UDP Destination Port is
  203.    a 16-bit field that contains the UDP protocol port number used to
  204.    demultiplex datagrams at the destination.  The UDP Source Port is a
  205.    16-bit field that contains the UDP protocol port number that
  206.    specifies the port to which replies should be sent when other
  207.    information is not available.  A zero setting indicates that no
  208.    source port number information is being provided.  When used with the
  209.    native IP DLC, this field is not used to convey a port number for
  210.    replies; moreover, the zero setting is not used.  IANA has registered
  211.    port numbers 12000 through 12004 for use in these two fields by the
  212.    native IP DLC; use of these port numbers allows prioritization in the
  213.    IP network.  For more details of the use of these fields, see 2.6.1,
  214.    "IP Prioritization" on page 28.
  215.  
  216.    The UDP Checksum is a 16-bit optional field that provides coverage of
  217.    the UDP header and the user data; it also provides coverage of a
  218.    pseudo-header that contains the source and destination IP addresses.
  219.    The UDP checksum is used to guarantee that the data has arrived
  220.    intact at the intended receiver.  When the UDP checksum is set to
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Dudley                       Informational                      [Page 4]
  227.  
  228. RFC 2353                APPN/HPR in IP Networks                 May 1998
  229.  
  230.  
  231.    zero, it indicates that the checksum was not calculated and should
  232.    not be checked by the receiver.  Use of the checksum is recommended
  233.    for use with the native IP DLC.
  234.  
  235.    IP provides an unreliable, connectionless delivery mechanism.  The IP
  236.    protocol defines the basic unit of data transfer through the IP
  237.    network, and performs the routing function (i.e., choosing the path
  238.    over which data will be sent).  In addition, IP characterizes how
  239.    "hosts" and "gateways" should process packets, the circumstances
  240.    under which error messages are generated, and the conditions under
  241.    which packets are discarded.  An IP version 4 header contains an 8-
  242.    bit Type of Service field that specifies how the datagram should be
  243.    handled.  As defined in RFC 1349 [8], the type-of-service byte
  244.    contains two defined fields.  The 3-bit precedence field allows
  245.    senders to indicate the priority of each datagram.  The 4-bit type of
  246.    service field indicates how the network should make tradeoffs between
  247.    throughput, delay, reliability, and cost.  The 8-bit Protocol field
  248.    specifies which higher-level protocol created the datagram.  When
  249.    used with the native IP DLC, this field is set to 17 which indicates
  250.    the higher-layer protocol is UDP.
  251.  
  252. 2.2  Node Structure
  253.  
  254.    Figure 1 on page 6 shows a possible node functional decomposition for
  255.    transport of HPR traffic across an IP network.  There will be
  256.    variations in different platforms based on platform characteristics.
  257.  
  258.    The native IP DLC includes a DLC manager, one LDLC component for each
  259.    link, and a link demultiplexor.  Because UDP is a connectionless
  260.    delivery service, there is no need for HPR to activate and deactivate
  261.    lower-level connections.
  262.  
  263.    The DLC manager activates and deactivates a link demultiplexor for
  264.    each port and an instance of LDLC for each link established in an IP
  265.    network.  Multiple links (e.g., one defined link and one dynamic link
  266.    for connection network traffic) may be established between a pair of
  267.    IP addresses.  Each link is identified by the source and destination
  268.    IP addresses in the IP header and the source and destination service
  269.    access point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0,
  270.    "Appendix - Packet Format" on page 37); the link demultiplexor passes
  271.    incoming packets to the correct instance of LDLC based on these
  272.    identifiers.  Moreover, the IP address pair associated with an active
  273.    link and used in the IP header may not change.
  274.  
  275.    LDLC also provides other functions (for example, reliable delivery of
  276.    Exchange Identification [XID] commands).  Error recovery for HPR RTP
  277.    packets is provided by the protocols between the RTP endpoints.
  278.  
  279.  
  280.  
  281.  
  282. Dudley                       Informational                      [Page 5]
  283.  
  284. RFC 2353                APPN/HPR in IP Networks                 May 1998
  285.  
  286.  
  287.    The network control layer (NCL) uses the automatic network routing
  288.    (ANR) information in the HPR network header to either pass incoming
  289.    packets to RTP or an outgoing link.
  290.  
  291.    All components are shown as single entities, but the number of
  292.    logical instances of each is as follows:
  293.  
  294.    o   DLC manager -- 1 per node
  295.  
  296.    o   LDLC -- 1 per link
  297.  
  298.    o   Link demultiplexor -- 1 per port
  299.  
  300.    o   NCL -- 1 per node (or 1 per port for efficiency)
  301.  
  302.    o   RTP -- 1 per RTP connection
  303.  
  304.    o   UDP -- 1 per port
  305.  
  306.    o   IP -- 1 per port
  307.  
  308.    Products are free to implement other structures.  Products
  309.    implementing other structures will need to make the appropriate
  310.    modifications to the algorithms and protocol boundaries shown in this
  311.    document.
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Dudley                       Informational                      [Page 6]
  339.  
  340. RFC 2353                APPN/HPR in IP Networks                 May 1998
  341.  
  342.  
  343.    --------------------------------------------------------------------
  344.  
  345.                                          -*
  346.       *-------------*       *-------*     |
  347.       |Configuration|       | Path  |     |
  348.       |   Services  |       |Control|     |
  349.       *-------------*       *-------*     |
  350.             A A                 A         |
  351.             | |                 |         |
  352.             | |                 V         |
  353.             | |              *-----*      | APPN/HPR
  354.             | |              | RTP |      |
  355.             | |              *-----*      |
  356.             | |                 A         |
  357.             | |                 |         |
  358.             | |                 V         |
  359.             | |              *-----*      |
  360.             | |              | NCL |      |
  361.             | |              *-----*      |
  362.             | *------------*    A        -*
  363.             |              |    |
  364.             V              V    V        -*
  365.           *---------*    *---------*      |
  366.           |   DLC   |--->|  LDLC   |      |
  367.           | manager |    |         |      |
  368.           *---------*    *---------*      |
  369.                |              A |         | IP DLC
  370.                *-----------*  | *----*    |
  371.                            V  |      |    |
  372.                          *---------* |    |
  373.                          |  LINK   | |    |
  374.                          |  DEMUX  | |    |
  375.                          *---------* |    |
  376.                               A    *-*   -*
  377.                               |    |
  378.                               |    V
  379.                            *---------*
  380.                            |   UDP   |
  381.                            *---------*
  382.                                 A
  383.                                 |
  384.                                 V
  385.                            *---------*
  386.                            |   IP    |
  387.                            *---------*
  388.  
  389.    --------------------------------------------------------------------
  390.                       Figure 1. HPR/IP Node Structure
  391.  
  392.  
  393.  
  394. Dudley                       Informational                      [Page 7]
  395.  
  396. RFC 2353                APPN/HPR in IP Networks                 May 1998
  397.  
  398.  
  399. 2.3  Logical Link Control (LLC) Used for IP
  400.  
  401.    Logical Data Link Control (LDLC) is used by the native IP DLC.  LDLC
  402.    is defined in [2].  LDLC uses a subset of the services defined by
  403.    IEEE 802.2 LLC type 2 (LLC2).  LDLC uses only the TEST, XID, DISC,
  404.    DM, and UI frames.
  405.  
  406.    LDLC was defined to be used in conjunction with HPR (with the HPR
  407.    Control Flows over RTP option set 1402) over reliable links that do
  408.    not require link-level error recovery.  Most frame loss in IP
  409.    networks (and the underlying frame networks) is due to congestion,
  410.    not problems with the facilities.  When LDLC is used on a link, no
  411.    link-level error recovery is available; as a result, only RTP traffic
  412.    is supported by the native IP DLC.  Using LDLC eliminates the need
  413.    for LLC2 and its associated cost (adapter storage, longer path
  414.    length, etc.).
  415.  
  416. 2.3.1  LDLC Liveness
  417.  
  418.    LDLC liveness (using the LDLC TEST command and response) is required
  419.    when the underlying subnetwork does not provide notification of
  420.    connection outage.  Because UDP is connectionless, it does not
  421.    provide outage notification; as a result, LDLC liveness is required
  422.    for HPR/IP links.
  423.  
  424.    Liveness should be sent periodically on active links except as
  425.    described in the following subsection when the option to reduce
  426.    liveness traffic is implemented.  The default liveness timer period
  427.    is 10 seconds.  When the defaults for the liveness timer and retry
  428.    timer (15 seconds) are used, the period between liveness tests is
  429.    smaller than the time required to detect failure (retry count
  430.    multiplied by retry timer period) and may be smaller than the time
  431.    for liveness to complete successfully (on the order of round-trip
  432.    delay).  When liveness is implemented as specified in the LDLC
  433.    finite-state machine (see [2]) this is not a problem because the
  434.    liveness protocol works as follows:  The liveness timer is for a
  435.    single link.  The timer is started when the link is first activated
  436.    and each time a liveness test completes successfully.  When the timer
  437.    expires, a liveness test is performed.  When the link is operational,
  438.    the period between liveness tests is on the order of the liveness
  439.    timer period plus the round-trip delay.
  440.  
  441.    For each implementation, it is necessary to check if the liveness
  442.    protocol will work in a satisfactory manner with the default settings
  443.    for the liveness and retry timers.  If, for example, the liveness
  444.    timer is restarted immediately upon expiration, then a different
  445.    default for the liveness timer should be used.
  446.  
  447.  
  448.  
  449.  
  450. Dudley                       Informational                      [Page 8]
  451.  
  452. RFC 2353                APPN/HPR in IP Networks                 May 1998
  453.  
  454.  
  455. 2.3.1.1  Option to Reduce Liveness Traffic
  456.  
  457.    In some environments, it is advantageous to reduce the amount of
  458.    liveness traffic when the link is otherwise idle.  (For example, this
  459.    could allow underlying facilities to be temporarily deactivated when
  460.    not needed.)  As an option, implementations may choose not to send
  461.    liveness when the link is idle (i.e., when data was neither sent nor
  462.    received over the link while the liveness timer was running).  (If
  463.    the implementation is not aware of whether data has been received,
  464.    liveness testing may be stopped while data is not being sent.)
  465.    However, the RTP connections also have a liveness mechanism which
  466.    will generate traffic.  Some implementations of RTP will allow
  467.    setting a large value for the ALIVE timer, thus reducing the amount
  468.    of RTP liveness traffic.
  469.  
  470.    If LDLC liveness is turned off while the link is idle, one side of
  471.    the link may detect a link failure much earlier than the other.  This
  472.    can cause the following problems:
  473.  
  474.    o   If a node that is aware of a link failure attempts to reactivate
  475.        the link, the partner node (unaware of the link failure) may
  476.        reject the activation as an unsupported parallel link between the
  477.        two ports.
  478.  
  479.    o   If a node that is unaware of an earlier link failure sends data
  480.        (including new session activations) on the link, it may be
  481.        discarded by a node that detected the earlier failure and
  482.        deactivated the link.  As a result, session activations would
  483.        fail.
  484.  
  485.    The mechanisms described below can be used to remedy these problems.
  486.    These mechanisms are needed only in a node not sending liveness when
  487.    the link is idle; thus, they would not be required of a node not
  488.    implementing this option that just happened to be adjacent to a node
  489.    implementing the option.
  490.  
  491.    o   (Mandatory unless the node supports multiple active defined links
  492.        between a pair of HPR/IP ports and supports multiple active
  493.        dynamic links between a pair of HPR/IP ports.)  Anytime a node
  494.        rejects the activation of an HPR/IP link as an unsupported
  495.        parallel link between a pair of HPR/IP ports (sense data
  496.        X'10160045' or X'10160046'), it should perform liveness on any
  497.        active link between the two ports that is using a different SAP
  498.        pair.  Thus, if the activation was not for a parallel link but
  499.        rather was a reactivation because one of these active links had
  500.        failed, the failed link will be detected.  (If the SAP pair for
  501.        the link being activated matches the SAP pair for an active link,
  502.        a liveness test would succeed because the adjacent node would
  503.  
  504.  
  505.  
  506. Dudley                       Informational                      [Page 9]
  507.  
  508. RFC 2353                APPN/HPR in IP Networks                 May 1998
  509.  
  510.  
  511.        respond for the link being activated.)  A simple way to implement
  512.        this function is for LDLC, upon receiving an activation XID, to
  513.        run liveness on all active links with a matching IP address pair
  514.        and a different SAP pair.
  515.  
  516.    o   (Mandatory) Anytime a node receives an activation XID with an IP
  517.        address pair and a SAP pair that match those of an active link,
  518.        it should deactivate the active link and allow it to be
  519.        reestablished.  A timer is required to prevent stray XIDs from
  520.        deactivating an active link.
  521.  
  522.    o   (Recommended) A node should attempt to reactivate an HPR/IP link
  523.        before acting on an LDLC-detected failure.  This mechanism is
  524.        helpful in preventing session activation failures in scenarios
  525.        where the other side detected a link failure earlier, but the
  526.        network has recovered.
  527.  
  528. 2.4  IP Port Activation
  529.  
  530.    The node operator (NO) creates a native IP DLC by issuing
  531.    DEFINE_DLC(RQ) (containing customer-configured parameters) and
  532.    START_DLC(RQ) commands to the node operator facility (NOF).  NOF, in
  533.    turn, passes DEFINE_DLC(RQ) and START_DLC(RQ) signals to
  534.    configuration services (CS), and CS creates the DLC manager.  Then,
  535.    the node operator can define a port by issuing DEFINE_PORT(RQ) (also
  536.    containing customer-configured parameters) to NOF with NOF passing
  537.    the associated signal to CS.
  538.  
  539.    A node with adapters attached to multiple IP subnetworks may
  540.    represent the multiple adapters as a single HPR/IP port.  However, in
  541.    that case, the node associates a single IP address with that port.
  542.    RFC 1122 [9] requires that a node with multiple adapters be able to
  543.    use the same source IP address on outgoing UDP packets regardless of
  544.    the adapter used for transmission.
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Dudley                       Informational                     [Page 10]
  563.  
  564. RFC 2353                APPN/HPR in IP Networks                 May 1998
  565.  
  566.  
  567.      *----------------------------------------------*
  568.      |  NOF                CS                  DLC  |
  569.      *----------------------------------------------*
  570.          . DEFINE_DLC(RQ)   .
  571.    1     o----------------->o
  572.          . DEFINE_DLC(RSP)  |
  573.    2     o<-----------------*
  574.          . START_DLC(RQ)    .      create
  575.    3     o----------------->o------------------->o
  576.          . START_DLC(RSP)   |                    .
  577.    4     o<-----------------*                    .
  578.          . DEFINE_PORT(RQ)  .                    .
  579.    5     o----------------->o                    .
  580.          . DEFINE_PORT(RSP) |                    .
  581.    6     o<-----------------*                    .
  582.  
  583.              Figure 2. IP Port Activation
  584.  
  585.    The following parameters are received in DEFINE_PORT(RQ):
  586.  
  587.    o   Port name
  588.  
  589.    o   DLC name
  590.  
  591.    o   Port type (if IP connection networks are supported, set to shared
  592.        access transport facility [SATF]; otherwise, set to switched)
  593.  
  594.    o   Link station role (set to negotiable)
  595.  
  596.    o   Maximum receive BTU size (default is 1461 [1492 less an allowance
  597.        for the IP, UDP, and LLC headers])
  598.  
  599.    o   Maximum send BTU size (default is 1461 [1492 less an allowance
  600.        for the IP, UDP, and LLC headers])
  601.  
  602.    o   Link activation limits (total, inbound, and outbound)
  603.  
  604.    o   IPv4 supported (set to yes)
  605.  
  606.    o   The local IPv4 address (required if IPv4 is supported)
  607.  
  608.    o   IPv6 supported (set to no; may be set to yes in the future; see
  609.        2.9, "IPv4-to-IPv6 Migration" on page 35)
  610.  
  611.    o   The local IPv6 address (required if IPv6 is supported)
  612.  
  613.    o   Retry count for LDLC (default is 3)
  614.  
  615.  
  616.  
  617.  
  618. Dudley                       Informational                     [Page 11]
  619.  
  620. RFC 2353                APPN/HPR in IP Networks                 May 1998
  621.  
  622.  
  623.    o   Retry timer period for LDLC (default is 15 seconds; a smaller
  624.        value such as 10 seconds can be used for a campus network)
  625.  
  626.    o   LDLC liveness timer period (default is 10 seconds; see 2.3.1,
  627.        "LDLC Liveness" on page 7)
  628.  
  629.    o   IP precedence (the setting of the 3-bit field within the Type of
  630.        Service byte of the IP header for the LLC commands such as XID
  631.        and for each of the APPN transmission priorities; the defaults
  632.        are given in 2.6.1, "IP Prioritization" on page 28.)
  633.  
  634. 2.4.1  Maximum BTU Sizes for HPR/IP
  635.  
  636.    When IP datagrams are larger than the underlying physical links
  637.    support, IP performs fragmentation.  When HPR/IP links are
  638.    established, the default maximum basic transmission unit (BTU) sizes
  639.    are 1461 bytes, which corresponds to the typical IP maximum
  640.    transmission unit (MTU) size of 1492 bytes supported by routers on
  641.    token-ring networks.  1461 is 1492 less 20 bytes for the IP header, 8
  642.    bytes for the UDP header, and 3 bytes for the IEEE 802.2 LLC header.
  643.    The IP header is larger than 20 bytes when optional fields are
  644.    included; smaller maximum BTU sizes should be configured if optional
  645.    IP header fields are used in the IP network.  For IPv6, the default
  646.    is reduced to 1441 bytes to allow for the typical IPv6 header size of
  647.    40 bytes.  Smaller maximum BTU sizes (but not less than 768) should
  648.    be used to avoid fragmentation when necessary.  Larger BTU sizes
  649.    should be used to improve performance when the customer's IP network
  650.    supports a sufficiently large IP MTU size.  The maximum receive and
  651.    send BTU sizes are passed to CS in DEFINE_PORT(RQ).  These maximum
  652.    BTU sizes can be overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ).
  653.  
  654.    The Flags field in the IP header should be set to allow
  655.    fragmentation.  Some products will not be able to control the setting
  656.    of the bit allowing fragmentation; in that case, fragmentation will
  657.    most likely be allowed.  Although fragmentation is slow and prevents
  658.    prioritization based on UDP port numbers, it does allow connectivity
  659.    across paths with small MTU sizes.
  660.  
  661. 2.5  IP Transmission Groups (TGs)
  662.  
  663. 2.5.1  Regular TGs
  664.  
  665.    Regular HPR TGs may be established in IP networks using the native IP
  666.    DLC architecture.  Each of these TGs is composed of one or more
  667.    HPR/IP links.  Configuration services (CS) identifies the TG with the
  668.    destination control point (CP) name and TG number; the destination CP
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Dudley                       Informational                     [Page 12]
  675.  
  676. RFC 2353                APPN/HPR in IP Networks                 May 1998
  677.  
  678.  
  679.    name may be configured or learned via XID, and the TG number, which
  680.    may be configured, is negotiated via XID.  For auto-activatable
  681.    links, the destination CP name and TG number must be configured.
  682.  
  683.    When multiple links (dynamic or defined) are established between a
  684.    pair of IP ports (each associated with a single IP address), an
  685.    incoming packet can be mapped to its associated link using the IP
  686.    address pair and the service access point (SAP) address pair.  If a
  687.    node receives an activation XID for a defined link with an IP address
  688.    pair and a SAP pair that are the same as for an active defined link,
  689.    that node can assume that the link has failed and that the partner
  690.    node is reactivating the link.  In such a case as an optimization,
  691.    the node receiving the XID can take down the active link and allow
  692.    the link to be reestablished in the IP network.  Because UDP packets
  693.    can arrive out of order, implementation of this optimization requires
  694.    the use of a timer to prevent a stray XID from deactivating an active
  695.    link.
  696.  
  697.    Support for multiple defined links between a pair of HPR/IP ports is
  698.    optional.  There is currently no value in defining multiple HPR/IP
  699.    links between a pair of ports.  In the future if HPR/IP support for
  700.    the Resource ReSerVation Protocol (RSVP) [10] is defined, it may be
  701.    advantageous to define such parallel links to segregate traffic by
  702.    COS on RSVP "sessions."  Using RSVP, HPR would be able to reserve
  703.    bandwidth in IP networks.  An HPR logical link would be mapped to an
  704.    RSVP "session" that would likely be identified by either a specific
  705.    application-provided UDP port number or a dynamically-assigned UDP
  706.    port number.
  707.  
  708.    When multiple defined HPR/IP links between ports are not supported,
  709.    an incoming activation for a defined HPR/IP link may be rejected with
  710.    sense data X'10160045' if an active defined HPR/IP link already
  711.    exists between the ports.  If the SAP pair in the activation XID
  712.    matches the SAP pair for the existing link, the optimization
  713.    described above may be used instead.
  714.  
  715.    If parallel defined HPR/IP links between ports are not supported, an
  716.    incoming activation XID is mapped to the defined link station (if it
  717.    exists) associated with the port on the adjacent node using the
  718.    source IP address in the incoming activation XID.  This source IP
  719.    address should be the same as the destination IP address associated
  720.    with the matching defined link station.  (They may not be the same if
  721.    the adjacent node has multiple IP addresses, and the configuration
  722.    was not coordinated correctly.)
  723.  
  724.    If parallel HPR/IP links between ports are supported, multiple
  725.    defined link stations may be associated with the port on the adjacent
  726.    node.  In that case, predefined TG numbers (see "Partitioning the TG
  727.  
  728.  
  729.  
  730. Dudley                       Informational                     [Page 13]
  731.  
  732. RFC 2353                APPN/HPR in IP Networks                 May 1998
  733.  
  734.  
  735.    Number Space" in Chapter 9 Configuration Services of [1]) may be used
  736.    to map the XID to a specific link station.  However, because the same
  737.    TG characteristics may be used for all HPR/IP links between a given
  738.    pair of ports, all the link stations associated with the port in the
  739.    adjacent node should be equivalent; as a result, TG number
  740.    negotiation using negotiable TG numbers may be used.
  741.  
  742.    In the future, if multiple HPR/IP links with different
  743.    characteristics are defined between a pair of ports using RSVP,
  744.    defined link stations will need sufficient configured information to
  745.    be matched with incoming XIDs.  (Correct matching of an incoming XID
  746.    to a defined link station allows CS to provide the correct TG
  747.    characteristics to topology and routing services (TRS).)  At that
  748.    time CS will do the mapping based on both the IP address of the
  749.    adjacent node and a predefined TG number.
  750.  
  751.    The node initiating link activation knows which link it is
  752.    activating.  Some parameters sent in prenegotiation XID are defined
  753.    in the regular link station configuration and not allowed to change
  754.    in following negotiation-proceeding XIDs.  To allow for forward
  755.    migration to RSVP, when a regular TG is activated in an IP network,
  756.    the node receiving the first XID (i.e., the node not initiating link
  757.    activation) must also understand which defined link station is being
  758.    activated before sending a prenegotiation XID in order to correctly
  759.    set parameters that cannot change.  For this reason, the node
  760.    initiating link activation will indicate the TG number in
  761.    prenegotiation XIDs by including a TG Descriptor (X'46') control
  762.    vector containing a TG Identifier (X'80') subfield.  Furthermore, the
  763.    node receiving the first XID will force the node activating the link
  764.    to send the first prenegotiation XID by responding to null XIDs with
  765.    null XIDs.  To prevent potential deadlocks, the node receiving the
  766.    first XID has a limit (the LDLC retry count can be used) on the
  767.    number of null XIDs it will send.  Once this limit is reached, that
  768.    node will send an XID with an XID Negotiation Error (X'22') control
  769.    vector in response to a null XID; sense data X'0809003A' is included
  770.    in the control vector to indicate unexpected null XID.  If the node
  771.    that received the first XID receives a prenegotiation XID without the
  772.    TG Identifier subfield, it will send an XID with an XID Negotiation
  773.    Error control vector to reject the link connection; sense data
  774.    X'088C4680' is included in the control vector to indicate the
  775.    subfield was missing.
  776.  
  777.    For a regular TG, the TG parameters are provided by the node operator
  778.    based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ).
  779.    The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP
  780.    links:
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Dudley                       Informational                     [Page 14]
  787.  
  788. RFC 2353                APPN/HPR in IP Networks                 May 1998
  789.  
  790.  
  791.    o   The destination IP host name (this parameter can usually be
  792.        mapped to the destination IP address):  If the link is not
  793.        activated at node initialization, the IP host name should be
  794.        mapped to an IP address, and the IP address should be stored with
  795.        the link station definition.  This is required to allow an
  796.        incoming link activation to be matched with the link station
  797.        definition.  If the adjacent node activates the link with a
  798.        different IP address (e.g., it could have multiple ports), it
  799.        will not be possible to match the link activation with the link
  800.        station definition, and the default parameters specified in the
  801.        local port definition will be used.
  802.  
  803.    o   The destination IP version (set to version 4, support for version
  804.        6 may be required in the future; this parameter is only required
  805.        if the address and version cannot be determined using the
  806.        destination IP host name.)
  807.  
  808.    o   The destination IP address (in the format specified by the
  809.        destination IP version; this parameter is only required if the
  810.        address cannot be determined using the destination IP host name.)
  811.  
  812.    o   Source service access point address (SSAP) used for XID, TEST,
  813.        DISC, and DM (default is X'04'; other values may be specified
  814.        when multiple links between a pair of IP addresses are defined)
  815.  
  816.    o   Destination service access point address (DSAP) used for XID,
  817.        TEST, DISC, and DM (default is X'04')
  818.  
  819.    o   Source service access point address (SSAP) used for HPR network
  820.        layer packets (NLPs) (default is X'C8'; other values may be
  821.        specified when multiple links between a pair of IP addresses are
  822.        defined.)
  823.  
  824.    o   Maximum receive BTU size (default is 1461; this parameter is used
  825.        to override the setting in DEFINE_PORT.)
  826.  
  827.    o   Maximum send BTU size (default is 1461; this parameter is used to
  828.        override the setting in DEFINE_PORT.)
  829.  
  830.    o   IP precedence (the setting of the 3-bit field within the Type of
  831.        Service byte of the IP header for LLC commands such as XID and
  832.        for each of the APPN transmission priorities; the defaults are
  833.        given in 2.6.1, "IP Prioritization" on page 28; this parameter is
  834.        used to override the settings in DEFINE_PORT)
  835.  
  836.    o   Shareable with connection network traffic (default is yes for
  837.        non-RSVP links)
  838.  
  839.  
  840.  
  841.  
  842. Dudley                       Informational                     [Page 15]
  843.  
  844. RFC 2353                APPN/HPR in IP Networks                 May 1998
  845.  
  846.  
  847.    o   Retry count for LDLC (default is 3; this parameter is used to
  848.        override the setting in DEFINE_PORT)
  849.  
  850.    o   Retry timer period for LDLC (default is 15 seconds; a smaller
  851.        value such as 10 seconds can be used for a campus link; this
  852.        parameter is used to override the setting in DEFINE_PORT)
  853.  
  854.    o   LDLC liveness timer period (default is 10 seconds; this parameter
  855.        is to override the setting in DEFINE_PORT; see 2.3.1, "LDLC ness"
  856.        on page 7)
  857.  
  858.    o   Auto-activation supported (default is no; may be set to yes when
  859.        the local node has switched access to the IP network)
  860.  
  861.    o   Limited resource (default is to set in concert with auto-
  862.        activation supported)
  863.  
  864.    o   Limited resource liveness timer (default is 45 sec.)
  865.  
  866.    o   Port name
  867.  
  868.    o   Adjacent CP name (optional)
  869.  
  870.    o   Local CP-CP sessions supported
  871.  
  872.    o   Defined TG number (optional)
  873.  
  874.    o   TG characteristics
  875.  
  876.    The following figures show the activation and deactivation of regular
  877.    TGs.
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Dudley                       Informational                     [Page 16]
  899.  
  900. RFC 2353                APPN/HPR in IP Networks                 May 1998
  901.  
  902.  
  903. *------------------------------------------------------------------*
  904. |CS              DLC             LDLC           DMUX            UDP|
  905. *------------------------------------------------------------------*
  906.  .                .                              .               .
  907.  .CONNECT_OUT(RQ) .  create                      .               .
  908.  o--------------->o-------------->o              .               .
  909.  .                |        new LDLC              .               .
  910.  .                o----------------------------->o               .
  911.  CONNECT_OUT(+RSP)|               .              .               .
  912.  o<---------------*               .              .               .
  913.  |               XID              .           XID(CMD)           . XID
  914.  *------------------------------->o----------------------------->o----->
  915.  
  916.                Figure 3. Regular TG Activation (outgoing)
  917.  
  918.    In Figure 3 upon receiving START_LS(RQ) from NOF, CS starts the link
  919.    activation process by sending CONNECT_OUT(RQ) to the DLC manager.
  920.    The DLC manager creates an instance of LDLC for the link, informs the
  921.    link demultiplexor, and sends CONNECT_OUT(+RSP) to CS.  Then, CS
  922.    starts the activation XID exchange.
  923.  
  924. *------------------------------------------------------------------*
  925. |CS              DLC             LDLC           DMUX            UDP|
  926. *------------------------------------------------------------------*
  927.  .                .                              .               .
  928.  . CONNECT_IN(RQ) .          XID(CMD)            .     XID       . XID
  929.  o<---------------o<-----------------------------o<--------------o<-----
  930.  | CONNECT_IN(RSP).    create                    .               .
  931.  *--------------->o-------------->o              .               .
  932.  .                |          new LDLC            .               .
  933.  .                o----------------------------->o               .
  934.  .                |  XID(CMD)     .              .               .
  935.  .                *-------------->o              .               .
  936.  .               XID              |              .               .
  937.  o<-------------------------------*              .               .
  938.  |               XID              .            XID(RSP)          . XID
  939.  *------------------------------->o----------------------------->o----->
  940.  
  941.                Figure 4. Regular TG Activation (incoming)
  942.  
  943.    In Figure 4, when an XID is received for a new link, it is passed to
  944.    the DLC manager.  The DLC manager sends CONNECT_IN(RQ) to notify CS
  945.    of the incoming link activation, and CS sends CONNECT_IN(+RSP)
  946.    accepting the link activation.  The DLC manager then creates a new
  947.    instance of LDLC, informs the link demultiplexor, and forwards the
  948.    XID to to CS via LDLC.  CS then responds by sending an XID to the
  949.    adjacent node.
  950.  
  951.  
  952.  
  953.  
  954. Dudley                       Informational                     [Page 17]
  955.  
  956. RFC 2353                APPN/HPR in IP Networks                 May 1998
  957.  
  958.  
  959.    The two following figures show normal TG deactivation (outgoing and
  960.    incoming).
  961.  
  962. *------------------------------------------------------------------*
  963. |CS              DLC             LDLC           DMUX            UDP|
  964. *------------------------------------------------------------------*
  965.  .                .               .              .               .
  966.  .             DEACT              .            DISC              . DISC
  967.  o------------------------------->o----------------------------->o----->
  968.  .             DEACT              .       DM     .       DM      . DM
  969.  o<-------------------------------o<-------------o<--------------o<-----
  970.  | DISCONNECT(RQ) .    destroy    .              .               .
  971.  *--------------->o-------------->o              .               .
  972.   DISCONNECT(RSP) |                              .               .
  973.  o<---------------*                              .               .
  974.  
  975.               Figure 5. Regular TG Deactivation (outgoing)
  976.  
  977.    In Figure 5 upon receiving STOP_LS(RQ) from NOF, CS sends DEACT to
  978.    notify the partner node that the HPR link is being deactivated.  When
  979.    the response is received, CS sends DISCONNECT(RQ) to the DLC manager,
  980.    and the DLC manager deactivates the instance of LDLC.  Upon receiving
  981.    DISCONNECT(RSP), CS sends STOP_LS(RSP) to NOF.
  982.  
  983. *------------------------------------------------------------------*
  984. |CS              DLC             LDLC           DMUX            UDP|
  985. *------------------------------------------------------------------*
  986.  .                .               .              .               .
  987.  .             DEACT              .      DISC    .      DISC     . DISC
  988.  o<-------------------------------o<-------------o<--------------o<-----
  989.  |                .               |             DM               . DM
  990.  |                .               *----------------------------->o----->
  991.  | DISCONNECT(RQ) .    destroy    .              .               .
  992.  *--------------->o-------------->o              .               .
  993.  .DISCONNECT(RSP) |                              .               .
  994.  o<---------------*                              .               .
  995.  
  996.               Figure 6. Regular TG Deactivation (incoming)
  997.  
  998.    In Figure 6, when an adjacent node deactivates a TG, the local node
  999.    receives a DISC.  CS sends STOP_LS(IND) to NOF.  Because IP is
  1000.    connectionless, the DLC manager is not aware that the link has been
  1001.    deactivated.  For that reason, CS also needs to send DISCONNECT(RQ)
  1002.    to the DLC manager; the DLC manager deactivates the instance of LDLC.
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Dudley                       Informational                     [Page 18]
  1011.  
  1012. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1013.  
  1014.  
  1015. 2.5.1.1  Limited Resources and Auto-Activation
  1016.  
  1017.    To reduce tariff charges, the APPN architecture supports the
  1018.    definition of switched links as limited resources.  A limited-
  1019.    resource link is deactivated when there are no sessions traversing
  1020.    the link.  Intermediate HPR nodes are not aware of sessions between
  1021.    logical units (referred to as LU-LU sessions) carried in crossing RTP
  1022.    connections; in HPR nodes, limited-resource TGs are deactivated when
  1023.    no traffic is detected for some period of time.  Furthermore, APPN
  1024.    links may be defined as auto-activatable.  Auto-activatable links are
  1025.    activated when a new session has been routed across the link.
  1026.  
  1027.    An HPR node may have access to an IP network via a switched access
  1028.    link.  In such environments, it may be advisable for customers to
  1029.    define regular HPR/IP links as limited resources and as being auto-
  1030.    activatable.
  1031.  
  1032. 2.5.2  IP Connection Networks
  1033.  
  1034.    Connection network support for IP networks (option set 2010), is
  1035.    described in this section.
  1036.  
  1037.    APPN architecture defines single link TGs across the point-to-point
  1038.    lines connecting APPN nodes.  The natural extension of this model
  1039.    would be to define a TG between each pair of nodes connected to a
  1040.    shared access transport facility (SATF) such as a LAN or IP network.
  1041.    However, the high cost of the system definition of such a mesh of TGs
  1042.    is prohibitive for a network of more than a few nodes.  For that
  1043.    reason, the APPN connection network model was devised to reduce the
  1044.    system definition required to establish TGs between APPN nodes.
  1045.  
  1046.    Other TGs may be defined through the SATF which are not part of the
  1047.    connection network.  Such TGs (referred to as regular TGs in this
  1048.    document) are required for sessions between control points (referred
  1049.    to as CP-CP sessions) but may also be used for LU-LU sessions.
  1050.  
  1051.    In the connection network model, a virtual routing node (VRN) is
  1052.    defined to represent the SATF.  Each node attached to the SATF
  1053.    defines a single TG to the VRN rather than TGs to all other attached
  1054.    nodes.
  1055.  
  1056.    Topology and routing services (TRS) specifies that a session is to be
  1057.    routed between two nodes across a connection network by including the
  1058.    connection network TGs between each of those nodes and the VRN in the
  1059.    Route Selection control vector (RSCV).  When a network node has a TG
  1060.    to a VRN, the network topology information associated with that TG
  1061.    includes DLC signaling information required to establish connectivity
  1062.    to that node across the SATF.  For an end node, the DLC signaling
  1063.  
  1064.  
  1065.  
  1066. Dudley                       Informational                     [Page 19]
  1067.  
  1068. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1069.  
  1070.  
  1071.    information is returned as part of the normal directory services (DS)
  1072.    process.  TRS includes the DLC signaling information for TGs across
  1073.    connection networks in RSCVs.
  1074.  
  1075.    CS creates a dynamic link station when the next hop in the RSCV of an
  1076.    ACTIVATE_ROUTE signal received from session services (SS) is a
  1077.    connection network TG or when an adjacent node initiates link
  1078.    activation upon receiving such an ACTIVATE_ROUTE signal.  Dynamic
  1079.    link stations are normally treated as limited resources, which means
  1080.    they are deactivated when no sessions are using them.  CP-CP sessions
  1081.    are not supported on connections using dynamic link stations because
  1082.    CP-CP sessions normally need to be kept up continuously.
  1083.  
  1084.    Establishment of a link across a connection network normally requires
  1085.    the use of CP-CP sessions to determine the destination IP address.
  1086.    Because CP-CP sessions must flow across regular TGs, the definition
  1087.    of a connection network does not eliminate the need to define regular
  1088.    TGs as well.
  1089.  
  1090.    Normally, one connection network is defined on a LAN (i.e., one VRN
  1091.    is defined.)  For an environment with several interconnected campus
  1092.    IP networks, a single wide-area connection network can be defined; in
  1093.    addition, separate connection networks can be defined between the
  1094.    nodes connected to each campus IP network.
  1095.  
  1096. 2.5.2.1  Establishing IP Connection Networks
  1097.  
  1098.    Once the port is defined, a connection network can be defined on the
  1099.    port.  In order to support multiple TGs from a port to a VRN, the
  1100.    connection network is defined by the following process:
  1101.  
  1102.    1.  A connection network and its associated VRN are defined on the
  1103.        port.  This is accomplished by the node operator issuing a
  1104.        DEFINE_CONNECTION_NETWORK(RQ) command to NOF and NOF passing a
  1105.        DEFINE_CN(RQ) signal to CS.
  1106.  
  1107.    2.  Each TG from the port to the VRN is defined by the node operator
  1108.        issuing DEFINE_CONNECTION_NETWORK_TG(RQ) to NOF and NOF passing
  1109.        DEFINE_CN_TG(RQ) to CS.
  1110.  
  1111.    Prior to implementation of Resource ReSerVation Protocol (RSVP)
  1112.    support, only one connection network TG between a port and a VRN is
  1113.    required.  In that case, product support for the DEFINE_CN_TG(RQ)
  1114.    signal is not required because a single set of port configuration
  1115.    parameters for each connection network is sufficient.  If a NOF
  1116.    implementation does not support DEFINE_CN_TG(RQ), the parameters
  1117.    listed in the following section for DEFINE_CN_TG(RQ), are provided by
  1118.    DEFINE_CN(RQ) instead.  Furthermore, the Connection Network TG
  1119.  
  1120.  
  1121.  
  1122. Dudley                       Informational                     [Page 20]
  1123.  
  1124. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1125.  
  1126.  
  1127.    Numbers (X'81') subfield in the TG Descriptor (X'46') control vector
  1128.    on an activation XID is only required to support multiple connection
  1129.    network TGs to a VRN, and its use is optional.
  1130.  
  1131.      *-----------------------------------------------------*
  1132.      |   NO                        NOF                CS   |
  1133.      *-----------------------------------------------------*
  1134.         DEFINE_CONNECTION_NETWORK(RQ)   DEFINE_CN(RQ)  .
  1135.           o------------------------>o----------------->o
  1136.        DEFINE_CONNECTION_NETWORK(RSP)   DEFINE_CN(RSP) |
  1137.           o<------------------------o<-----------------*
  1138.      DEFINE_CONNECTION_NETWORK_TG(RQ) DEFINE_CN_TG(RQ) .
  1139.           o------------------------>o----------------->o
  1140.     DEFINE_CONNECTION_NETWORK_TG(RSP) DEFINE_CN_TG(RSP)|
  1141.           o<------------------------o<-----------------*
  1142.  
  1143.           Figure 7. IP Connection Network Definition
  1144.  
  1145.    An incoming dynamic link activation may be rejected with sense data
  1146.    X'10160046' if there is an existing dynamic link between the two
  1147.    ports over the same connection network (i.e., with the same VRN CP
  1148.    name).  If a node receives an activation XID for a dynamic link with
  1149.    an IP address pair, a SAP pair, and a VRN CP name that are the same
  1150.    as for an active dynamic link, that node can assume that the link has
  1151.    failed and that the partner node is reactivating the link.  In such a
  1152.    case as an optimization, the node receiving the XID can take down the
  1153.    active link and allow the link to be reestablished in the IP network.
  1154.    Because UDP packets can arrive out of order, implementation of this
  1155.    optimization requires the use of a timer to prevent a stray XID from
  1156.    deactivating an active link.
  1157.  
  1158.    Once all the connection networks are defined, the node operator
  1159.    issues START_PORT(RQ), NOF passes the associated signal to CS, and CS
  1160.    passes ACTIVATE_PORT(RQ) to the DLC manager.  Upon receiving the
  1161.    ACTIVATE_PORT(RSP) signal from the DLC manager, CS sends a TG_UPDATE
  1162.    signal to TRS for each defined connection network TG.  Each signal
  1163.    notifies TRS that a TG to the VRN has been activated and includes TG
  1164.    vectors describing the TG.  If the port fails or is deactivated, CS
  1165.    sends TG_UPDATE indicating the connection network TGs are no longer
  1166.    operational.  Information about TGs between a network node and the
  1167.    VRN is maintained in the network topology database.  Information
  1168.    about TGs between an end node and the VRN is maintained only in the
  1169.    local topology database.  If TRS has no node entry in its topology
  1170.    database for the VRN, TRS dynamically creates such an entry.  A VRN
  1171.    node entry will become part of the network topology database only if
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Dudley                       Informational                     [Page 21]
  1179.  
  1180. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1181.  
  1182.  
  1183.    a network node has defined a TG to the VRN; however, TRS is capable
  1184.    of selecting a direct path between two end nodes across a connection
  1185.    network without a VRN node entry.
  1186.  
  1187. *--------------------------------------------------------------------*
  1188. |   CS                   TRS                 DLC               DMUX  |
  1189. *--------------------------------------------------------------------*
  1190.      .            ACTIVATE_PORT(RQ)           .     create
  1191.      o--------------------------------------->o----------------->o
  1192.      .            ACTIVATE_PORT(RSP)          |                  .
  1193.      o<---------------------------------------*                  .
  1194.      |  TG_UPDATE         .                   .                  .
  1195.      *------------------->o                   .                  .
  1196.      .                    .                   .                  .
  1197.  
  1198.            Figure 8. IP Connection Network Establishment
  1199.  
  1200. The TG vectors for IP connection network TGs include the following
  1201. information:
  1202.  
  1203.    o   TG number
  1204.  
  1205.    o   VRN CP name
  1206.  
  1207.    o   TG characteristics used during route selection
  1208.  
  1209.        -   Effective capacity
  1210.        -   Cost per connect time
  1211.        -   Cost per byte transmitted
  1212.        -   Security
  1213.        -   Propagation delay
  1214.        -   User defined parameters
  1215.  
  1216.    o   Signaling information
  1217.  
  1218.        -   IP version (indicates the format of the IP header including
  1219.            the IP address)
  1220.  
  1221.        -   IP address
  1222.  
  1223.        -   Link service access point address (LSAP) used for XID, TEST,
  1224.            DISC, and DM
  1225.  
  1226. 2.5.2.2  IP Connection Network Parameters
  1227.  
  1228.    For a connection network TG, the parameters are determined by CS
  1229.    using several inputs.  Parameters that are particular to the local
  1230.    port, connection network, or TG are system defined and received in
  1231.  
  1232.  
  1233.  
  1234. Dudley                       Informational                     [Page 22]
  1235.  
  1236. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1237.  
  1238.  
  1239.    DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ).  Signaling
  1240.    information for the destination node including its IP address is
  1241.    received in the ACTIVATE_ROUTE request from SS.
  1242.  
  1243.    The following configuration parameters are received in DEFINE_CN(RQ):
  1244.  
  1245.    o   Connection network name (CP name of the VRN)
  1246.  
  1247.    o   Limited resource liveness timer (default is 45 sec.)
  1248.  
  1249.    o   IP precedence (the setting of the 3-bit field within the Type of
  1250.        Service byte of the IP header for LLC commands such as XID and
  1251.        for each of the APPN transmission priorities; the defaults are
  1252.        given in 2.6.1, "IP Prioritization" on page 28; this parameter is
  1253.        used to override the settings in DEFINE_PORT)
  1254.  
  1255.    The following configuration parameters are received in
  1256.    DEFINE_CN_TG(RQ):
  1257.  
  1258.    o   Port name
  1259.  
  1260.    o   Connection network name (CP name of the VRN)
  1261.  
  1262.    o   Connection network TG number (set to a value between 1 and 239)
  1263.  
  1264.    o   TG characteristics (see 2.6.3, "Default TG Characteristics" on
  1265.        page 30)
  1266.  
  1267.    o   Link service access point address (LSAP) used for XID, TEST,
  1268.        DISC, and DM (default is X'04')
  1269.  
  1270.    o   Link service access point address (LSAP) used for HPR network
  1271.        layer packets (default is X'C8')
  1272.  
  1273.    o   Limited resource (default is yes)
  1274.  
  1275.    o   Retry count for LDLC (default is 3; this parameter is used to
  1276.        override the setting in DEFINE_PORT)
  1277.  
  1278.    o   Retry timer period for LDLC (default is 15 sec.; a smaller value
  1279.        such as 10 seconds can be used for a campus connection network;
  1280.        this parameter is used to override the setting in DEFINE_PORT)
  1281.  
  1282.    o   LDLC liveness timer period (default is 10 seconds; this parameter
  1283.        is used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC
  1284.        Liveness" on page 7)
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Dudley                       Informational                     [Page 23]
  1291.  
  1292. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1293.  
  1294.  
  1295.    o   Shareable with other HPR traffic (default is yes for non-RSVP
  1296.        links)
  1297.  
  1298.    o   Maximum receive BTU size (default is 1461; this parameter is used
  1299.        to override the value in DEFINE_PORT(RQ).)
  1300.  
  1301.    o   Maximum send BTU size (default is 1461; this parameter is used to
  1302.        override the value in DEFINE_PORT(RQ).)
  1303.  
  1304.    The following parameters are received in ACTIVATE_ROUTE for
  1305.    connection network TGs:
  1306.  
  1307.    o   The TG pair
  1308.  
  1309.    o   The destination IP version (if this version is not supported by
  1310.        the local node, the ACTIVATE_ROUTE_RSP reports the activation
  1311.        failure with sense data X'086B46A5'.)
  1312.  
  1313.    o   The destination IP address (in the format specified by the
  1314.        destination IP version)
  1315.  
  1316.    o   Destination service access point address (DSAP) used for XID,
  1317.        TEST, DISC, and DM
  1318.  
  1319. 2.5.2.3  Sharing of TGs
  1320.  
  1321.    Connection network traffic is multiplexed onto a regular defined IP
  1322.    TG (usually used for CP-CP session traffic) in order to reduce the
  1323.    control block storage.  No XIDs flow to establish a new TG on the IP
  1324.    network, and no new LLC is created.  When a regular TG is shared,
  1325.    incoming traffic is demultiplexed using the normal means.  If the
  1326.    regular TG is deactivated, a path switch is required for the HPR
  1327.    connection network traffic sharing the TG.
  1328.  
  1329.    Multiplexing is possible if the following conditions hold:
  1330.  
  1331.    1.  Both the regular TG and the connection network TG to the VRN are
  1332.        defined as shareable between HPR traffic streams.
  1333.  
  1334.    2.  The destination IP address is the same.
  1335.  
  1336.    3.  The regular TG is established first.  (Because links established
  1337.        for connection network traffic do not support CP-CP sessions,
  1338.        there is little value in allowing a regular TG to share such a
  1339.        link.)
  1340.  
  1341.    The destination node is notified via XID when a TG can be shared
  1342.    between HPR data streams.  At either end, upon receiving
  1343.  
  1344.  
  1345.  
  1346. Dudley                       Informational                     [Page 24]
  1347.  
  1348. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1349.  
  1350.  
  1351.    ACTIVATE_ROUTE requesting a shared TG for connection network traffic,
  1352.    CS checks its TGs for one meeting the required specifications before
  1353.    initiating a new link.  First, CS looks for a link established for
  1354.    the TG pair; if there is no such link, CS determines if there is a
  1355.    regular TG that can be shared and, if multiple such TGs exist, which
  1356.    TG to choose.  As a result, RTP connections routed over the same TG
  1357.    pair may actually use different links, and RTP connections routed
  1358.    over different TG pairs may use the same link.
  1359.  
  1360. 2.5.2.4  Minimizing RSCV Length
  1361.  
  1362.    The maximum length of a Route Selection (X'2B') control vector (RSCV)
  1363.    is 255 bytes.  Use of connection networks significantly increases the
  1364.    size of the RSCV contents required to describe a "hop" across an
  1365.    SATF.  First, because two connection network TGs are used to specify
  1366.    an SATF hop, two TG Descriptor (X'46') control vectors are required.
  1367.    Furthermore, inclusion of DLC signaling information within the TG
  1368.    Descriptor control vectors increases the length of these control
  1369.    vectors.  As a result, the total number of hops that can be specified
  1370.    in RSCVs traversing connection networks is reduced.
  1371.  
  1372.    To avoid unnecessarily limiting the number of hops, a primary goal in
  1373.    designing the formats for IP signaling information is to minimize
  1374.    their size.  Additional techniques are also used to reduce the effect
  1375.    of the RSCV length limitation.
  1376.  
  1377.    For an IP connection network, DLC signaling information is required
  1378.    only for the second TG (i.e., from the VRN to the destination node);
  1379.    the signaling information for the first TG is locally defined at the
  1380.    origin node.  For this reason, the topology database does not include
  1381.    DLC signaling information for the entry describing a connection
  1382.    network TG from a network node to a VRN.  The DLC signaling
  1383.    information is included in the allied entry for the TG in the
  1384.    opposite direction.  This mechanism cannot be used for a connection
  1385.    network TG between a VRN and an end node.  However, a node
  1386.    implementing IP connection networks does not include IP signaling
  1387.    information for the first connection network TG when constructing an
  1388.    RSCV.
  1389.  
  1390.    In an environment where APPN network nodes are used to route between
  1391.    legacy LANs and wide-area IP networks, it is recommended that
  1392.    customers not define connection network TGs between these network
  1393.    nodes and VRNs representing legacy LANs.  Typically, defined links
  1394.    are required between end nodes on the legacy LANs and such network
  1395.    nodes which also act as network node servers for the end nodes.
  1396.    These defined links can be used for user traffic as well as control
  1397.    traffic.  This technique will reduce the number of connection network
  1398.    hops in RSCVs between end nodes on different legacy LANs.
  1399.  
  1400.  
  1401.  
  1402. Dudley                       Informational                     [Page 25]
  1403.  
  1404. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1405.  
  1406.  
  1407.    Lastly, for environments where RSCVs are still not able to include
  1408.    enough hops, extended border nodes (EBNs) can be used to partition
  1409.    the network.  In this case, the EBNs will also provide piecewise
  1410.    subnet route calculation and RSCV swapping.  Thus, the entire route
  1411.    does not need to be described in a single RSCV with its length
  1412.    limitation.
  1413.  
  1414. 2.5.3  XID Changes
  1415.  
  1416.    Packets transmitted over IP networks are lost or arrive out of order
  1417.    more often than packets transmitted over other "link" technologies.
  1418.    As a result, the following problem with the XID3 negotiation protocol
  1419.    was exposed:
  1420.  
  1421.    --------------------------------------------------------------------
  1422.  
  1423.          *---------------------------------*
  1424.          |Node A                     Node B|
  1425.          *---------------------------------*
  1426.                           o
  1427.                           o
  1428.                           o
  1429.                            XID3 (np, NEG)
  1430.              o<-------------------------o
  1431.              |XID3 (np, SEC)
  1432.              *------------------------->o
  1433.                           XID3 (np, PRI)|
  1434.                         lost<-----------*
  1435.  
  1436.            time out
  1437.               XID3 (np, SEC)
  1438.              o------------------------->o
  1439.                                SETMODE  |
  1440.              o<-------------------------*
  1441.     fail because never
  1442.     received XID3 (np, PRI)
  1443.  
  1444.    Notation: np  - negotiation proceeding
  1445.              NEG - negotiable link station role
  1446.              SEC - secondary link station role
  1447.              PRI - primary link station role
  1448.  
  1449.    --------------------------------------------------------------------
  1450.                       Figure 9. XID3 Protocol Problem
  1451.  
  1452.    In the above sequence, the XID3(np, PRI), which is a link-level
  1453.    response to the received XID3(np, SEC), is lost.  Node A times out
  1454.    and resends the XID3(np, SEC) as a link-level command.  When Node B
  1455.  
  1456.  
  1457.  
  1458. Dudley                       Informational                     [Page 26]
  1459.  
  1460. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1461.  
  1462.  
  1463.    receives this command, it thinks that the XID3(np, PRI) was
  1464.    successfully received by Node A and that the activation XID exchange
  1465.    is complete.  As a result, Node B sends SETMODE (SNRM, SABME, or
  1466.    XID_DONE_RQ, depending upon the link type).  When Node A receives
  1467.    SETMODE, it fails the link activation because it has not received an
  1468.    XID3(np, PRI) from Node B confirming that Node B does indeed agree to
  1469.    be the primary.  Moreover, there are similar problems with incomplete
  1470.    TG number negotiation.
  1471.  
  1472.    To solve the problems with incomplete role and TG number negotiation,
  1473.    two new indicators are defined in XID3.  The problems are solved only
  1474.    if both link stations support these new indicators:
  1475.  
  1476.    o   Negotiation Complete Supported indicator (byte 12 bit 0) -- this
  1477.        1-bit field indicates whether the Negotiation Complete indicator
  1478.        is supported.  This field is meaningful when the XID exchange
  1479.        state is negotiation proceeding; otherwise, it is reserved.  A
  1480.        value of 0 means the Negotiation Complete indicator is not
  1481.        supported; a value of 1 means the indicator is supported.
  1482.  
  1483.    o   Negotiation Complete indicator (byte 12 bit 1) -- this 1-bit
  1484.        field is meaningful only when the XID exchange state is
  1485.        negotiation proceeding, the XID3 is sent by the secondary link
  1486.        station, and the Negotiation Complete Supported indicator is set
  1487.        to 1; otherwise, this field is reserved.  This field is set to 1
  1488.        by a secondary link station that supports enhanced XID
  1489.        negotiation when it considers the activation XID negotiation to
  1490.        be complete for both link station role and TG number (i.e., it is
  1491.        ready to receive a SETMODE command from the primary link
  1492.        station.)
  1493.  
  1494.    When a primary link station that supports enhanced XID negotiation
  1495.    receives an XID3(np) with both the Negotiation Complete Supported
  1496.    indicator and the Negotiation Complete indicator set to 1, the
  1497.    primary link station will know that it can safely send SETMODE if it
  1498.    also considers the XID negotiation to be complete.  The new
  1499.    indicators are used as shown in the following sequence when both the
  1500.    primary and secondary link stations support enhanced XID negotiation.
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Dudley                       Informational                     [Page 27]
  1515.  
  1516. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1517.  
  1518.  
  1519.    --------------------------------------------------------------------
  1520.  
  1521.          *----------------------------------*
  1522.          |Node A                     Node B |
  1523.          *----------------------------------*
  1524.                           o
  1525.                           o
  1526.                           o
  1527.                     XID3 (np, NEG, S, ^C)
  1528.    1         o<--------------------------o
  1529.              |XID3 (np, SEC, S, ^C)
  1530.    2         *-------------------------->o
  1531.                     XID3 (np, PRI, S, ^C)|
  1532.    3                    lost <-----------*
  1533.  
  1534.            time out
  1535.               XID3 (np, SEC, S, ^C)
  1536.    4         o-------------------------->o
  1537.                     XID3 (np, PRI, S, ^C)|
  1538.    5         o<--------------------------*
  1539.              |XID3 (np, SEC, S, C)
  1540.    6         *-------------------------->o
  1541.                                 SETMODE  |
  1542.    7         o<--------------------------*
  1543.  
  1544.    ^S indicates that byte 12 bit 0 is set to 0.
  1545.     S indicates that byte 12 bit 0 is set to 1.
  1546.    ^C indicates that byte 12 bit 1 is set to 0.
  1547.     C indicates that byte 12 bit 1 is set to 1.
  1548.  
  1549.    --------------------------------------------------------------------
  1550.    Figure 10. Enhanced XID Negotiation
  1551.  
  1552.    When Node B receives the XID in flow 4, it realizes that the Node A
  1553.    does not consider XID negotiation to be complete; as a result, it
  1554.    resends its current XID information in flow 5.  When Node A receives
  1555.    this XID, it responds in flow 6 with an XID that indicates XID
  1556.    negotiation is complete.  At this point, Node B, acting as the
  1557.    primary link station, sends SETMODE, and the link is activated
  1558.    successfully.
  1559.  
  1560.    Migration cases with only one link station supporting enhanced XID
  1561.    negotiation are shown in the two following sequences.  In the next
  1562.    sequence, only Node A (acting as the secondary link station) supports
  1563.    the new function.
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Dudley                       Informational                     [Page 28]
  1571.  
  1572. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1573.  
  1574.  
  1575.    --------------------------------------------------------------------
  1576.  
  1577.          *---------------------------------*
  1578.          |Node A                     Node B|
  1579.          *---------------------------------*
  1580.                           o
  1581.                           o
  1582.                           o
  1583.                        XID3 (np, NEG, ^S)
  1584.    1         o<--------------------------o
  1585.              |XID3 (np, SEC, S, ^C)
  1586.    2         *-------------------------->o
  1587.                        XID3 (np, PRI, ^S)|
  1588.    3                    lost <-----------*
  1589.  
  1590.            time out
  1591.               XID3 (np, SEC, S, ^C)
  1592.    4         o-------------------------->o
  1593.                                 SETMODE  |
  1594.    5         o<--------------------------*
  1595.            fail
  1596.  
  1597.  
  1598.    --------------------------------------------------------------------
  1599.                       Figure 11. First Migration Case
  1600.  
  1601.    The XID negotiation fails because Node B does not understand the new
  1602.    indicators and responds to flow 4 with SETMODE.
  1603.  
  1604.    In the next sequence, Node B supports the new indicators but Node A
  1605.    does not.
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Dudley                       Informational                     [Page 29]
  1627.  
  1628. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1629.  
  1630.  
  1631.    --------------------------------------------------------------------
  1632.  
  1633.          *---------------------------------*
  1634.          |Node A                     Node B|
  1635.          *---------------------------------*
  1636.                           o
  1637.                           o
  1638.                           o
  1639.                     XID3 (np, NEG, S, ^C)
  1640.    1         o<--------------------------o
  1641.              |XID3 (np, SEC, ^S)
  1642.    2         *-------------------------->o
  1643.                     XID3 (np, PRI, S, ^C)|
  1644.    3                    lost <-----------*
  1645.  
  1646.            time out
  1647.               XID3 (np, SEC, ^S)
  1648.    4         o-------------------------->o
  1649.                                  SETMODE |
  1650.    5         o<--------------------------*
  1651.            fail
  1652.  
  1653.  
  1654.    ------------------------------------------------------------------------
  1655.                      Figure 12. Second Migration Case
  1656.  
  1657.    The XID negotiation fails because Nobe A does not understand the new
  1658.    indicators and thus cannot indicate that it thinks XID negotiation is
  1659.    not complete in flow 4.  Node B understands that the secondary link
  1660.    station (node A) does not support the new indicators and respond with
  1661.    SETMODE in flow 5.
  1662.  
  1663.    Products that support HPR/IP links are required to support enhanced
  1664.    XID negotiation.  Moreover, it is recommended that products
  1665.    implementing this solution for HPR/IP links also support it for other
  1666.    link types.
  1667.  
  1668. 2.5.4  Unsuccessful IP Link Activation
  1669.  
  1670.    Link activation may fail for several different reasons.  When link
  1671.    activation over a connection network or of an auto-activatable link
  1672.    is attempted upon receiving ACTIVATE_ROUTE from SS, activation
  1673.    failure is reported with ACTIVATE_ROUTE_RSP containing sense data
  1674.    explaining the cause of failure.  Likewise, when activation fails for
  1675.    other regular defined links, the failure is reported with
  1676.    START_LS(RSP) containing sense data.
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Dudley                       Informational                     [Page 30]
  1683.  
  1684. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1685.  
  1686.  
  1687.    As is normal for session activation failures, the sense data is also
  1688.    sent to the node that initiated the session.  At the APPN-to-HPR
  1689.    boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data
  1690.    control vector is generated and returned to the primary logical unit
  1691.    (PLU).
  1692.  
  1693.    At an intermediate HPR node, link activation failure can be reported
  1694.    with sense data X'08010000' or X'80020000'.  At a node with route-
  1695.    selection responsibility, such failure can be reported with sense
  1696.    data X'80140001'.
  1697.  
  1698.    The following table contains the sense data for the various causes of
  1699.    link activation failure:
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Dudley                       Informational                     [Page 31]
  1739.  
  1740. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1741.  
  1742.  
  1743. +----------------------------------------------------------------------+
  1744. | Table 1 (Page 1 of 2). Native IP DLC Link Activation Failure Sense   |
  1745. |                        Data                                          |
  1746. +--------------------------------------------------------+-------------+
  1747. | ERROR DESCRIPTION                                      | SENSE DATA  |
  1748. +--------------------------------------------------------+-------------+
  1749. | The link specified in the RSCV is not available.       | X'08010000' |
  1750. +--------------------------------------------------------+-------------+
  1751. | The limit for null XID responses by a called node was  | X'0809003A' |
  1752. | reached.                                               |             |
  1753. +--------------------------------------------------------+-------------+
  1754. | A BIND was received over a subarea link, but the next  | X'08400002' |
  1755. | hop is over a port that supports only HPR links.  The  |             |
  1756. | receiver does not support this configuration.          |             |
  1757. +--------------------------------------------------------+-------------+
  1758. | The contents of the DLC Signaling Type (X'91')         | X'086B4691' |
  1759. | subfield of the TG Descriptor (X'46') control vector   |             |
  1760. | contained in the RSCV were invalid.                    |             |
  1761. +--------------------------------------------------------+-------------+
  1762. | The contents of the IP Address and Link Service Access | X'086B46A5' |
  1763. | Point Address (X'A5') subfield of the TG Descriptor    |             |
  1764. | (X'46') control vector contained in the RSCV were      |             |
  1765. | invalid.                                               |             |
  1766. +--------------------------------------------------------+-------------+
  1767. | No DLC Signaling Type (X'91') subfield was found in    | X'086D4691' |
  1768. | the TG Descriptor (X'46') control vector contained in  |             |
  1769. | the RSCV.                                              |             |
  1770. +--------------------------------------------------------+-------------+
  1771. | No IP Address and Link Service Access Point Address    | X'086D46A5' |
  1772. | (X'A5') subfield was found in the TG Descriptor        |             |
  1773. | (X'46') control vector contained in the RSCV.          |             |
  1774. +--------------------------------------------------------+-------------+
  1775. | Multiple sets of DLC signaling information were found  | X'08770019' |
  1776. | in the TG Descriptor (X'46') control vector contained  |             |
  1777. | in the RSCV.  IP supports only one set of DLC          |             |
  1778. | signaling information.                                 |             |
  1779. +--------------------------------------------------------+-------------+
  1780. | Link Definition Error:  A link is defined as not       | X'08770026' |
  1781. | supporting HPR, but the port only supports HPR links.  |             |
  1782. +--------------------------------------------------------+-------------+
  1783. | A called node found no TG Identifier (X'80') subfield  | X'088C4680' |
  1784. | within a TG Descriptor (X'46') control vector in a     |             |
  1785. | prenegotiation XID for a defined link in an IP         |             |
  1786. | network.                                               |             |
  1787. +--------------------------------------------------------+-------------+
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Dudley                       Informational                     [Page 32]
  1795.  
  1796. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1797.  
  1798.  
  1799. +----------------------------------------------------------------------+
  1800. | Table 1 (Page 2 of 2). Native IP DLC Link Activation Failure Sense   |
  1801. |                        Data                                          |
  1802. +--------------------------------------------------------+-------------+
  1803. | The XID3 received from the adjacent node does not      | X'10160031' |
  1804. | contain an HPR Capabilities (X'61') control vector.    |             |
  1805. | The IP port supports only HPR links.                   |             |
  1806. +--------------------------------------------------------+-------------+
  1807. | The RTP Supported indicator is set to 0 in the HPR     | X'10160032' |
  1808. | Capabilities (X'61') control vector of the XID3        |             |
  1809. | received from the adjacent node.  The IP port supports |             |
  1810. | only links to nodes that support RTP.                  |             |
  1811. +--------------------------------------------------------+-------------+
  1812. | The Control Flows over RTP Supported indicator is set  | X'10160033' |
  1813. | to 0 in the HPR Capabilities (X'61') control vector of |             |
  1814. | the XID3 received from the adjacent node.  The IP port |             |
  1815. | supports only links to nodes that support control      |             |
  1816. | flows over RTP.                                        |             |
  1817. +--------------------------------------------------------+-------------+
  1818. | The LDLC Supported indicator is set to 0 in the HPR    | X'10160034' |
  1819. | Capabilities (X'61') control vector of the XID3        |             |
  1820. | received from the adjacent node.  The IP port supports |             |
  1821. | only links to nodes that support LDLC.                 |             |
  1822. +--------------------------------------------------------+-------------+
  1823. | The HPR Capabilities (X'61') control vector received   | X'10160044' |
  1824. | in XID3 does not include an IEEE 802.2 LLC (X'80') HPR |             |
  1825. | Capabilities subfield.  The subfield is required on an |             |
  1826. | IP link.                                               |             |
  1827. +--------------------------------------------------------+-------------+
  1828. | Multiple defined links between a pair of switched      | X'10160045' |
  1829. | ports is not supported by the local node.  A link      |             |
  1830. | activation request was received for a defined link,    |             |
  1831. | but there is an active defined link between the paired |             |
  1832. | switched ports.                                        |             |
  1833. +--------------------------------------------------------+-------------+
  1834. | Multiple dynamic links across a connection network     | X'10160046' |
  1835. | between a pair of switched ports is not supported by   |             |
  1836. | the local node.  A link activation request was         |             |
  1837. | received for a dynamic link, but there is an active    |             |
  1838. | dynamic link between the paired switched ports across  |             |
  1839. | the same connection network.                           |             |
  1840. +--------------------------------------------------------+-------------+
  1841. | Link failure                                           | X'80020000' |
  1842. +--------------------------------------------------------+-------------+
  1843. | Route selection services has determined that no path   | X'80140001' |
  1844. | to the destination node exists for the specified COS.  |             |
  1845. +--------------------------------------------------------+-------------+
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Dudley                       Informational                     [Page 33]
  1851.  
  1852. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1853.  
  1854.  
  1855. 2.6  IP Throughput Characteristics
  1856.  
  1857. 2.6.1  IP Prioritization
  1858.  
  1859.    Typically, IP routers process packets on a first-come-first-served
  1860.    basis; i.e., no packets are given transmission priority.  However,
  1861.    some IP routers prioritize packets based on IP precedence (the 3-bit
  1862.    field within the Type of Service byte of the IP header) or UDP port
  1863.    numbers.  (With the current plans for IP security, the UDP port
  1864.    numbers are encrypted; as a result, IP routers would not be able to
  1865.    prioritize encrypted traffic based on the UDP port numbers.)  HPR
  1866.    will be able to exploit routers that provide priority function.
  1867.  
  1868.    The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by
  1869.    the Internet Assigned Number Authority (IANA).  Four of these port
  1870.    numbers are used for ANR-routed network layer packets (NLPs) and
  1871.    correspond to the APPN transmission priorities (network, 12001; high,
  1872.    12002; medium, 12003; and low, 12004), and one port number (12000) is
  1873.    used for a set of LLC commands (i.e., XID, TEST, DISC, and DM) and
  1874.    function-routed NLPs (i.e., XID_DONE_RQ and XID_DONE_RSP).  These
  1875.    port numbers are used for "listening" and are also used in the
  1876.    destination port number field of the UDP header of transmitted
  1877.    packets.  The source port number field of the UDP header can be set
  1878.    either to one of these port numbers or to an ephemeral port number.
  1879.  
  1880.    The IP precedence for each transmission priority and for the set of
  1881.    LLC commands (including function-routed NLPs) are configurable.  The
  1882.    implicit assumption is that the precedence value is associated with
  1883.    priority queueing and not with bandwidth allocation; however,
  1884.    bandwidth allocation policies can be administered by matching on the
  1885.    precedence field.  The default mapping to IP precedence is shown in
  1886.    the following table:
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Dudley                       Informational                     [Page 34]
  1907.  
  1908. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1909.  
  1910.  
  1911.    +---------------------------------------------+
  1912.    | Table 2. Default IP Precedence Settings     |
  1913.    +----------------------+----------------------+
  1914.    | PRIORITY             |      PRECEDENCE      |
  1915.    +----------------------+----------------------+
  1916.    | LLC commands and     |          110         |
  1917.    | function-routed NLPs |                      |
  1918.    +----------------------+----------------------+
  1919.    | Network              |          110         |
  1920.    +----------------------+----------------------+
  1921.    | High                 |          100         |
  1922.    +----------------------+----------------------+
  1923.    | Medium               |          010         |
  1924.    +----------------------+----------------------+
  1925.    | Low                  |          001         |
  1926.    +----------------------+----------------------+
  1927.  
  1928.    As an example, with this default mapping, telnet, interactive ftp,
  1929.    and business-use web traffic could be mapped to a precedence value of
  1930.    011, and batch ftp could be mapped to a value of 000.
  1931.  
  1932.    These settings were devised based on the AIW's understanding of the
  1933.    intended use of IP precedence.  The use of IP precedence will be
  1934.    modified appropriately if the IETF standardizes its use differently.
  1935.    The other fields in the IP TOS byte are not used and should be set to
  1936.    0.
  1937.  
  1938.    For outgoing ANR-routed NLPs, the destination (and optionally the
  1939.    source) UDP port numbers and IP precedence are set based on the
  1940.    transmission priority specified in the HPR network header.
  1941.  
  1942.    It is expected that the native IP DLC architecture described in this
  1943.    document will be used primarily for private campus or wide-area
  1944.    intranets where the customer will be able to configure the routers to
  1945.    honor the transmission priority associated with the UDP port numbers
  1946.    or IP precedence.  The architecture can be used to route HPR traffic
  1947.    in the Internet; however, in that environment, routers do not
  1948.    currently provide the priority function, and customers may find the
  1949.    performance unacceptable.
  1950.  
  1951.    In the future, a form of bandwidth reservation may be possible in IP
  1952.    networks using the Resource ReSerVation Protocol (RSVP), or the
  1953.    differentiated services currently being studied by the Integrated
  1954.    Services working group of the IETF.  Bandwidth could be reserved for
  1955.    an HPR/IP link thus insulating the HPR traffic from congestion
  1956.    associated with the traffic of other protocols.
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Dudley                       Informational                     [Page 35]
  1963.  
  1964. RFC 2353                APPN/HPR in IP Networks                 May 1998
  1965.  
  1966.  
  1967. 2.6.2  APPN Transmission Priority and COS
  1968.  
  1969.    APPN transmission priority and class of service (COS) allow APPN TGs
  1970.    to be highly utilized with batch traffic without impacting the
  1971.    performance of response-time sensitive interactive traffic.
  1972.    Furthermore, scheduling algorithms guarantee that lower-priority
  1973.    traffic is not completely blocked.  The result is predictable
  1974.    performance.
  1975.  
  1976.    When a session is initiated across an APPN network, the session's
  1977.    mode is mapped into a COS and transmission priority.  For each COS,
  1978.    APPN has a COS table that is used in the route selection process to
  1979.    select the most appropriate TGs (based on their TG characteristics)
  1980.    for the session to traverse.  The TG characteristics and COS tables
  1981.    are defined such that APPN topology and routing services (TRS) will
  1982.    select the appropriate TG for the traffic of each COS.
  1983.  
  1984. 2.6.3  Default TG Characteristics
  1985.  
  1986.    In Chapter 7 (TRS) of [1], there is a set of SNA-defined TG default
  1987.    profiles.  When a TG (connection network or regular) is defined as
  1988.    being of a particular technology (e.g., ethernet or X.25) without
  1989.    specification of the TG's characteristics, parameters from the
  1990.    technology's default profile are used in the TG's topology entry.
  1991.    The customer is free to override these values via configuration.
  1992.    Some technologies have multiple profiles (e.g., ISDN has both a
  1993.    profile for switched and nonswitched.)  Two default profiles are
  1994.    required for IP TGs.  This many are needed because there are both
  1995.    campus and wide-area IP networks.  As a result for each HPR/IP TG, a
  1996.    customer should specify, at minimum, campus or wide area.  HPR/IP TGs
  1997.    traversing the Internet should be specified as wide-area links.  If
  1998.    no specification is made, a campus network is assumed.
  1999.  
  2000.    The 2 IP profiles are as follows:
  2001.  
  2002. +----------------------------------------------------------------------+
  2003. | Table 3. IP Default TG Characteristics                               |
  2004. +-------------------+---------+----------+---------+---------+---------+
  2005. |                   | Cost    | Cost per | Security| Propa-  | Effec-  |
  2006. |                   | per     | byte     |         | gation  | tive    |
  2007. |                   | connect |          |         | delay   | capacity|
  2008. |                   | time    |          |         |         |         |
  2009. +-------------------+---------+----------+---------+---------+---------+
  2010. | Campus            | 0       | 0        | X'01'   | X'71'   | X'75'   |
  2011. +-------------------+---------+----------+---------+---------+---------+
  2012. | Wide area         | 0       | 0        | X'20'   | X'91'   | X'43'   |
  2013. +-------------------+---------+----------+---------+---------+---------+
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Dudley                       Informational                     [Page 36]
  2019.  
  2020. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2021.  
  2022.  
  2023.    Typically, a TG is either considered to be "free" if it is owned or
  2024.    leased or "costly" if it is a switched carrier facility.  Free TGs
  2025.    have 0 for both cost parameters, and costly TGs have 128 for both
  2026.    parameters.  For campus IP networks, the default for both cost
  2027.    parameters is 0.
  2028.  
  2029.    It is less clear what the defaults should be for wide area.  Because
  2030.    a router normally has leased access to an IP network, the defaults
  2031.    for both costs are also 0.  This assumes the IP network is not
  2032.    tariffed.  However, if the IP network is tariffed, then the customer
  2033.    should set the cost per byte to 0 or 128 depending on whether the
  2034.    tariff contains a component based on quantity of data transmitted,
  2035.    and the customer should set the cost per connect time to 0 or 128
  2036.    based on whether there is a tariff component based on connect time.
  2037.    Furthermore, for switched access to the IP network, the customer
  2038.    settings for both costs should also reflect the tariff associated
  2039.    with the switched access link.
  2040.  
  2041.    Only architected values (see "Security" in [1]) may be used for a
  2042.    TG's security parameter.  The default security value is X'01'
  2043.    (lowest) for campus and X'20' (public switched network; secure in the
  2044.    sense that there is no predetermined route the traffic will take) for
  2045.    wide-area IP networks.  The network administrator may override the
  2046.    default value but should, in that case, ensure that an appropriate
  2047.    level of security exists.
  2048.  
  2049.    For wide area, the value X'91' (packet switched) is the default for
  2050.    propagation delay; this is consistent with other wide-area facilities
  2051.    and indicates that IP packets will experience both terrestrial
  2052.    propagation delay and queueing delay in intermediate routers.  This
  2053.    value is suitable for both the Internet and wide-area intranets;
  2054.    however, the customer could use different values to favor intranets
  2055.    over the Internet during route selection.  The value X'99' (long) may
  2056.    be appropriate for some international links across the Internet.  For
  2057.    campus, the default is X'71' (terrestrial); this setting essentially
  2058.    equates the queueing delay in IP networks with terrestrial
  2059.    propagation delay.
  2060.  
  2061.    For wide area, X'43' (56 kbs) is shown as the default effective
  2062.    capacity; this is at the low-end of typical speeds for wide-area IP
  2063.    links.  For campus, X'75' (4 Mbs) is the default; this is at the
  2064.    low-end of typical speeds for campus IP links.  However, customers
  2065.    should set the effective capacity for both campus and wide area IP
  2066.    links based on the actual physical speed of the access link to the IP
  2067.    network; for regular links, if both the source and destination access
  2068.    speeds are known, customers should set the effective capacity based
  2069.    on the minimum of these two link speeds.  If there are multiple
  2070.    access links, the capacity setting should be based on the physical
  2071.  
  2072.  
  2073.  
  2074. Dudley                       Informational                     [Page 37]
  2075.  
  2076. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2077.  
  2078.  
  2079.    speed of the access link that is expected to be used for the link.
  2080.  
  2081.    For the encoding technique for effective capacity in the topology
  2082.    database, see "Effective Capacity" in Chapter 7, Topology and Routing
  2083.    Services of [1].  The table in that section can be extended as
  2084.    follows for higher speeds:
  2085.  
  2086. +----------------------------------------------------------------------+
  2087. | Table 4. Calculated Effective Capacity Representations               |
  2088. +-----------------------------------+----------------------------------+
  2089. | Link Speed (Approx.)              | Effective Capacity               |
  2090. +-----------------------------------+----------------------------------+
  2091. | 25M                               | X'8A'                            |
  2092. +-----------------------------------+----------------------------------+
  2093. | 45M                               | X'91'                            |
  2094. +-----------------------------------+----------------------------------+
  2095. | 100M                              | X'9A'                            |
  2096. +-----------------------------------+----------------------------------+
  2097. | 155M                              | X'A0'                            |
  2098. +-----------------------------------+----------------------------------+
  2099. | 467M                              | X'AC'                            |
  2100. +-----------------------------------+----------------------------------+
  2101. | 622M                              | X'B0'                            |
  2102. +-----------------------------------+----------------------------------+
  2103. | 1G                                | X'B5'                            |
  2104. +-----------------------------------+----------------------------------+
  2105. | 1.9G                              | X'BC'                            |
  2106. +-----------------------------------+----------------------------------+
  2107.  
  2108. 2.6.4  SNA-Defined COS Tables
  2109.  
  2110.    SNA-defined batch and interactive COS tables are provided in [1].
  2111.    These tables are enhanced in [2] (see section 18.7.2) for the
  2112.    following reasons:
  2113.  
  2114.    o   To ensure that the tables assign reasonable weights to ATM TGs
  2115.        relative to each other and other technologies based on cost,
  2116.        speed, and delay
  2117.  
  2118.    o   To facilitate use of other new higher-speed facilities - This
  2119.        goal is met by providing several speed groupings above 10 Mbps.
  2120.        To keep the tables from growing beyond 12 rows, low-speed
  2121.        groupings are merged.
  2122.  
  2123.    Products implementing the native IP DLC should use the new COS
  2124.    tables.  Although the effective capacity values in the old tables are
  2125.    sufficient for typical IP speeds, the new tables are valuable because
  2126.    higher-speed links can be used for IP networks.
  2127.  
  2128.  
  2129.  
  2130. Dudley                       Informational                     [Page 38]
  2131.  
  2132. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2133.  
  2134.  
  2135. 2.6.5  Route Setup over HPR/IP links
  2136.  
  2137.    The Resequence ("REFIFO") indicator is set in Route Setup request and
  2138.    reply when the RTP path uses a multi-link TG because packets may not
  2139.    be received in the order sent.  The Resequence indicator is also set
  2140.    when the RTP path includes an HPR/IP link as packets sent over an IP
  2141.    network may arrive out of order.
  2142.  
  2143.    Adaptive rate-based congestion control (ARB) is an HPR Rapid
  2144.    Transport Protocol (RTP) function that controls the data transmission
  2145.    rate over RTP connections.  ARB also provides fairness between the
  2146.    RTP traffic streams sharing a link.  For ARB to perform these
  2147.    functions in the IP environment, it is necessary to coordinate the
  2148.    ARB parameters with the IP TG characteristics.  This is done for IP
  2149.    links in a similar manner to that done for other link types.
  2150.  
  2151. 2.6.6  Access Link Queueing
  2152.  
  2153.    Typically, nodes implementing the native IP DLC have an access link
  2154.    to a network of IP routers.  These IP routers may be providing
  2155.    prioritization based on UDP port numbers or IP precedence.  A node
  2156.    implementing the native IP DLC can be either an IP host or an IP
  2157.    router; in both cases, such nodes should also honor the priorities
  2158.    associated with either the UDP port numbers or the IP precedence when
  2159.    transmitting HPR data over the access link to the IP network.
  2160.  
  2161. --------------------------------------------------------------------
  2162.  
  2163. *--------* access link *--------*     *--------*
  2164. |  HPR   |-------------|   IP   |-----|   IP   |
  2165. |  node  |             | Router |     | Router |
  2166. *--------*             *--------*     *--------*
  2167.                             |              |
  2168.                             |              |
  2169.                             |              |
  2170.                        *--------*     *--------* access link *--------*
  2171.                        |   IP   |-----|   IP   |-------------|  HPR   |
  2172.                        | Router |     | Router |             |  node  |
  2173.                        *--------*     *--------*             *--------*
  2174.  
  2175.  
  2176. --------------------------------------------------------------------
  2177.                         Figure 13. Access Links
  2178.  
  2179.    Otherwise, the priority function in the router network will be
  2180.    negated with the result being HPR interactive traffic delayed by
  2181.    either HPR batch traffic or the traffic of other higher-layer
  2182.    protocols at the access link queues.
  2183.  
  2184.  
  2185.  
  2186. Dudley                       Informational                     [Page 39]
  2187.  
  2188. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2189.  
  2190.  
  2191. 2.7  Port Link Activation Limits
  2192.  
  2193.    Three parameters are provided by NOF to CS on DEFINE_PORT(RQ) to
  2194.    define the link activation limits for a port: total limit, inbound
  2195.    limit, and outbound limit.  The total limit is the desired maximum
  2196.    number of active link stations allowed on the port for both regular
  2197.    TGs and connection network TGs.  The inbound limit is the desired
  2198.    number of link stations reserved for connections initiated by
  2199.    adjacent nodes; the purpose of this field is to insure that a minimum
  2200.    number of link stations may be activated by adjacent nodes.  The
  2201.    outbound limit is the desired number of link stations reserved for
  2202.    connections initiated by the local node.  The sum of the inbound and
  2203.    outbound limits must be less than or equal to the total limit.  If
  2204.    the sum is less than the total limit, the difference is the number of
  2205.    link stations that can be activated on a demand basis as either
  2206.    inbound or outbound.  These limits should be based on the actual
  2207.    adapter capability and the node's resources (e.g., control blocks).
  2208.  
  2209.    A connection network TG will be reported to topology as quiescing
  2210.    when its port's total limit threshold is reached; likewise, an
  2211.    inactive auto-activatable regular TG is reported as nonoperational.
  2212.    When the number of active link stations drops far enough below the
  2213.    threshold (e.g., so that at least 20 percent of the original link
  2214.    activation limit has been recovered), connection network TGs are
  2215.    reported as not quiescing, and auto-activatable TGs are reported as
  2216.    operational.
  2217.  
  2218. 2.8  Network Management
  2219.  
  2220.    APPN and HPR management information is defined by the APPN MIB (RFC
  2221.    2155 [11]) and the HPR MIB (RFC 2238 [13]).  In addition, the SNANAU
  2222.    working group of the IETF plans to define an HPR-IP-MIB that will
  2223.    provide HPR/IP-specific management information.  In particular, this
  2224.    MIB will provide a mapping of APPN traffic types to IP Type of
  2225.    Service Precedence values, as well as a count of UDP packets sent for
  2226.    each traffic type.
  2227.  
  2228.    There are also rules that must be specified concerning the values an
  2229.    HPR/IP implementation returns for objects in the APPN MIB:
  2230.  
  2231.    o   Several objects in the APPN MIB have the syntax IANAifType.  The
  2232.        value 126, defined as "IP (for APPN HPR in IP networks)" should
  2233.        be returned by the following three objects when they identify an
  2234.        HPR/IP link:
  2235.  
  2236.        -   appnPortDlcType
  2237.        -   appnLsDlcType
  2238.        -   appnLsStatusDlcType
  2239.  
  2240.  
  2241.  
  2242. Dudley                       Informational                     [Page 40]
  2243.  
  2244. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2245.  
  2246.  
  2247.    o   Link-level addresses are reported in the following objects:
  2248.  
  2249.        -   appnPortDlcLocalAddr
  2250.        -   appnLsLocalAddr
  2251.        -   appnLsRemoteAddr
  2252.        -   appnLsStatusLocalAddr
  2253.        -   appnLsStatusRemoteAddr
  2254.  
  2255.        All of these objects should return ASCII character strings that
  2256.        represent IP addresses in the usual dotted-decimal format.  (At
  2257.        this point it's not clear what the "usual...format" will be for
  2258.        IPv6 addresses, but whatever it turns out to be, that is what
  2259.        these objects will return when an HPR/IP link traverses an IP
  2260.        network.)
  2261.  
  2262.    o   The following two objects return Object Identifiers that tie
  2263.        table entries in the APPN MIB to entries in lower-layer MIBs:
  2264.  
  2265.        -   appnPortSpecific
  2266.        -   appnLsSpecific
  2267.  
  2268.        Both of these objects should return the same value:  a RowPointer
  2269.        to the ifEntry in the agent's ifTable for the physical interface
  2270.        associated with the local IP address for the port.  If the agent
  2271.        implements the IP-MIB (RFC 2011 [12]), this association between
  2272.        the IP address and the physical interface will be represented in
  2273.        the ipNetToMediaTable.
  2274.  
  2275. 2.9  IPv4-to-IPv6 Migration
  2276.  
  2277.    The native IP DLC is architected to use IP version 4 (IPv4).
  2278.    However, support for IP version 6 (IPv6) may be required in the
  2279.    future.
  2280.  
  2281.    IP routers and hosts can interoperate only if both ends use the same
  2282.    version of the IP protocol.  However, most IPv6 implementations
  2283.    (routers and hosts) will actually have dual IPv4/IPv6 stacks.  IPv4
  2284.    and IPv6 traffic can share transmission facilities provided that the
  2285.    router/host at each end has a dual stack.  IPv4 and IPv6 traffic will
  2286.    coexist on the same infrastructure in most areas.  The version number
  2287.    in the IP header is used to map incoming packets to either the IPv4
  2288.    or IPv6 stack.  A dual-stack host which wishes to talk to an IPv4
  2289.    host will use IPv4.
  2290.  
  2291.    Hosts which have an IPv4 address can use it as an IPv6 address using
  2292.    a special IPv6 address prefix (i.e., it is an embedded IPv4 address).
  2293.    This mapping was provided mainly for "legacy" application
  2294.    compatibility purposes as such applications don't have the socket
  2295.  
  2296.  
  2297.  
  2298. Dudley                       Informational                     [Page 41]
  2299.  
  2300. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2301.  
  2302.  
  2303.    structures needed to store full IPv6 addresses.  Two IPv6 hosts may
  2304.    communicate using IPv6 with embedded-IPv4 addresses.
  2305.  
  2306.    Both IPv4 and IPv6 addresses can be stored by the domain name service
  2307.    (DNS). When an application queries DNS, it asks for IPv4 addresses,
  2308.    IPv6 addresses, or both. So, it's the application that decides which
  2309.    stack to use based on which addresses it asks for.
  2310.  
  2311.    Migration for HPR/IP ports will work as follows:
  2312.  
  2313.    An HPR/IP port is configured to support IPv4, IPv6, or both.  If IPv4
  2314.    is supported, a local IPv4 address is defined; if IPv6 is supported,
  2315.    a local IPv6 address (which can be an embedded IPv4 address) is
  2316.    defined.  If both IPv4 and IPv6 are supported, both a local IPv4
  2317.    address and a local IPv6 address are defined.
  2318.  
  2319.    Defined links will work as follows:  If the local node supports IPv4
  2320.    only, a destination IPv4 address may be defined, or an IP host name
  2321.    may be defined in which case DNS will be queried for an IPv4 address.
  2322.    If the local node supports IPv6 only, a destination IPv6 address may
  2323.    be defined, or an IP host name may be defined in which case DNS will
  2324.    be queried for an IPv6 address.  If both IPv4 and IPv6 are supported,
  2325.    a destination IPv4 address may be defined, a destination IPv6 address
  2326.    may be defined, or an IP host name may be defined in which case DNS
  2327.    will be queried for both IPv4 and IPv6 addresses; if provided by DNS,
  2328.    an IPv6 address can be used, and an IPv4 address can be used
  2329.    otherwise.
  2330.  
  2331.    Separate IPv4 and IPv6 connection networks can be defined.  If the
  2332.    local node supports IPv4, it can define a connection network TG to
  2333.    the IPv4 VRN.  If the local node supports IPv6, it can define a TG to
  2334.    the IPv6 VRN.  If both are supported, TGs can be defined to both
  2335.    VRNs.  Therefore, the signaling information received in RSCVs will be
  2336.    compatible with the local node's capabilities unless a configuration
  2337.    error has occurred.
  2338.  
  2339. 3.0  References
  2340.  
  2341.    [1]  IBM, Systems Network Architecture Advanced Peer-to-Peer
  2342.    Networking Architecture Reference, SC30-3442-04. Viewable at URL:
  2343.    http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS
  2344.  
  2345.    [2]  IBM, Systems Network Architecture Advanced Peer-to-Peer
  2346.    Networking High Performance Routing Architecture Reference, Version
  2347.    3.0, SV40-1018-02.  Viewable at URL: http://www.raleigh.ibm.com/cgi-
  2348.    bin/bookmgr/BOOKS/D50H6001/CCONTENTS
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Dudley                       Informational                     [Page 42]
  2355.  
  2356. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2357.  
  2358.  
  2359.    [3]  IBM, Systems Network Architecture Formats, GA27-3136-16.
  2360.    Viewable at URL: http://www.raleigh.ibm.com/cgi-
  2361.    bin/bookmgr/BOOKS/D50A5003/CCONTENTS
  2362.  
  2363.    [4]  Wells, L. and A. Bartky, "Data Link Switching: Switch-to-Switch
  2364.    Protocol, AIW DLSw RIG:  DLSw Closed Pages, DLSw Standard Version
  2365.    1.0", RFC 1795, April 1995.
  2366.  
  2367.    [5]  Bryant, D. and P. Brittain, "APPN Implementers' Workshop Closed
  2368.    Pages Document DLSw v2.0 Enhancements", RFC 2166, June 1997.
  2369.  
  2370.    [6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
  2371.    1980.
  2372.  
  2373.    [7]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  2374.  
  2375.    [8]  Almquist, P., "Type of Service in the Internet Protocol Suite",
  2376.    RFC 1349, July 1992.
  2377.  
  2378.    [9]  Braden, R., "Requirements for Internet Hosts -- Communication
  2379.    Layers", STD 3, RFC 1122, October 1989.
  2380.  
  2381.    [10] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
  2382.    "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
  2383.    Specification", RFC 2205, September 1997.
  2384.  
  2385.    [11] Clouston, B., and B. Moore, "Definitions of Managed Objects for
  2386.    APPN using SMIv2", RFC 2155, June 1997.
  2387.  
  2388.    [12] McCloghrie, K., "SNMPv2 Management Information Base for the
  2389.    Internet Protocol using SMIv2", RFC 2011, November 1996.
  2390.  
  2391.    [13] Clouston, B., and B. Moore, "Definitions of Managed Objects for
  2392.    HPR using SMIv2", RFC 2238, November 1997.
  2393.  
  2394. 4.0  Security Considerations
  2395.  
  2396.    For HPR, the IP network appears to be a link.  For that reason, the
  2397.    SNA session-level security functions (user authentication, LU
  2398.    authentication, session encryption, etc.) are still available for
  2399.    use.  In addition, as HPR traffic flows as UDP datagrams through the
  2400.    IP network, IPsec can be used to provide network-layer security
  2401.    inside the IP network.
  2402.  
  2403.    There are firewall considerations when supporting HPR traffic using
  2404.    the native IP DLC.  First, the firewall filters can be set to allow
  2405.    the HPR traffic to pass.  Traffic can be restricted based on the
  2406.    source and destination IP addresses and the destination port number;
  2407.  
  2408.  
  2409.  
  2410. Dudley                       Informational                     [Page 43]
  2411.  
  2412. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2413.  
  2414.  
  2415.    the source port number is not relevant.  That is, the firewall should
  2416.    accept traffic with the IP addresses of the HPR/IP nodes and with
  2417.    destination port numbers in the range 12000 to 12004.  Second, the
  2418.    possibility exists for an attack using forged UDP datagrams; such
  2419.    attacks could cause the RTP connection to fail or even introduce
  2420.    false data on a session.  In environments where such attacks are
  2421.    expected, the use of network-layer security is recommended.
  2422.  
  2423. 5.0  Author's Address
  2424.  
  2425.    Gary Dudley
  2426.    C3BA/501
  2427.    IBM Corporation
  2428.    P.O. Box 12195
  2429.    Research Triangle Park, NC 27709, USA
  2430.  
  2431.    Phone: +1 919-254-4358
  2432.    Fax:   +1 919-254-6243
  2433.    EMail: dudleyg@us.ibm.com
  2434.  
  2435.  
  2436.  
  2437.  
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Dudley                       Informational                     [Page 44]
  2467.  
  2468. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2469.  
  2470.  
  2471. 6.0  Appendix - Packet Format
  2472.  
  2473. 6.1  HPR Use of IP Formats
  2474.  
  2475. +----------------------------------------------------------------------+
  2476. | 6.1.1  IP Format for LLC Commands and Responses                      |
  2477. |                                                                      |
  2478. |                     The formats described here are used for the      |
  2479. |                     following LLC commands and responses:  XID       |
  2480. |                     command and response, TEST command and response, |
  2481. |                     DISC command, and DM response.                   |
  2482. +----------------------------------------------------------------------+
  2483.  
  2484.  
  2485. +----------------------------------------------------------------------+
  2486. | IP Format for LLC Commands and Responses                             |
  2487. +-------+-----+--------------------------------------------------------+
  2488. | Byte  | Bit | Content                                                |
  2489. +-------+-----+--------------------------------------------------------+
  2490. +-------+-----+--------------------------------------------------------+
  2491. | 0-p   |     | IP header (see note 1)                                 |
  2492. +-------+-----+--------------------------------------------------------+
  2493. +-------+-----+--------------------------------------------------------+
  2494. | p+1-  |     | UDP header (see note 2)                                |
  2495. | p+8   |     |                                                        |
  2496. +-------+-----+--------------------------------------------------------+
  2497. +-------+-----+--------------------------------------------------------+
  2498. | p+9-  |     | IEEE 802.2 LLC header (see note 3)                     |
  2499.                 _____________________
  2500. | p+11  |     |                                                        |
  2501. +-------+-----+--------------------------------------------------------+
  2502. +-------+-----+--------------------------------------------------------+
  2503. | p+9   |     | DSAP:  same as for the base APPN (i.e., X'04' or an    |
  2504. |       |     | installation-defined value)                            |
  2505. +-------+-----+--------------------------------------------------------+
  2506. +-------+-----+--------------------------------------------------------+
  2507. | p+10  |     | SSAP:  same as for the base APPN (i.e., X'04' or an    |
  2508. |       |     | installation-defined value)                            |
  2509. +-------+-----+--------------------------------------------------------+
  2510. +-------+-----+--------------------------------------------------------+
  2511. | p+11  |     | Control: set as appropriate                            |
  2512. +-------+-----+--------------------------------------------------------+
  2513. +-------+-----+--------------------------------------------------------+
  2514. | p+12-n|     | Remainder of PDU:  XID3 or TEST information field, or  |
  2515. |       |     | null for DISC command and DM response                  |
  2516. +-------+-----+--------------------------------------------------------+
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Dudley                       Informational                     [Page 45]
  2523.  
  2524. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2525.  
  2526.  
  2527. +-------+-----+--------------------------------------------------------+
  2528. |       |     | Note 1:  Rules for encoding the IP header can be found |
  2529. |       |     | in RFC 791.                                            |
  2530. +-------+-----+--------------------------------------------------------+
  2531. +-------+-----+--------------------------------------------------------+
  2532. |       |     | Note 2:  Rules for encoding the UDP header can be      |
  2533. |       |     | found in RFC 768.                                      |
  2534. +-------+-----+--------------------------------------------------------+
  2535.  
  2536. +----------------------------------------------------------------------+
  2537. | IP Format for LLC Commands and Responses                             |
  2538. +-------+-----+--------------------------------------------------------+
  2539. | Byte  | Bit | Content                                                |
  2540. +-------+-----+--------------------------------------------------------+
  2541.  
  2542. +-------+-----+--------------------------------------------------------+
  2543. |       |     | Note 3:  Rules for encoding the IEEE 802.2 LLC header  |
  2544. |       |     | can be found in ISO/IEC 8802-2:1994 (ANSI/IEEE Std     |
  2545. |       |     | 802.2, 1994 Edition), Information technology -         |
  2546. |       |     | Telecommunications and information exchange between    |
  2547. |       |     | systems - Local and metropolitan area networks -       |
  2548. |       |     | Specific requirements - Part 2:  Logical Link Control. |
  2549. +-------+-----+--------------------------------------------------------+
  2550.  
  2551. +----------------------------------------------------------------------+
  2552. | 6.1.2  IP Format for NLPs in UI Frames                               |
  2553. |                                                                      |
  2554. |                     This format is used for either LDLC specific     |
  2555. |                     messages or HPR session and control traffic.     |
  2556. +----------------------------------------------------------------------+
  2557. +----------------------------------------------------------------------+
  2558. | IP Format for NLPs in UI Frames                                      |
  2559. +-------+-----+--------------------------------------------------------+
  2560. | Byte  | Bit | Content                                                |
  2561. +-------+-----+--------------------------------------------------------+
  2562. +-------+-----+--------------------------------------------------------+
  2563. | 0-p   |     | IP header (see note 1)                                 |
  2564. +-------+-----+--------------------------------------------------------+
  2565. +-------+-----+--------------------------------------------------------+
  2566. | p+1-  |     | UDP header (see note 2)                                |
  2567. | p+8   |     |                                                        |
  2568. +-------+-----+--------------------------------------------------------+
  2569. +-------+-----+--------------------------------------------------------+
  2570. | p+9-  |     | IEEE 802.2 LLC header                                  |
  2571.                 _____________________
  2572. | p+11  |     |                                                        |
  2573. +-------+-----+--------------------------------------------------------+
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Dudley                       Informational                     [Page 46]
  2579.  
  2580. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2581.  
  2582.  
  2583. +-------+-----+--------------------------------------------------------+
  2584. | p+9   |     | DSAP:  the destination SAP obtained from the IEEE      |
  2585. |       |     | 802.2 LLC (X'80') subfield in the HPR Capabilities     |
  2586. |       |     | (X'61') control vector in the received XID3 (see note  |
  2587. |       |     | 3)                                                     |
  2588. +-------+-----+--------------------------------------------------------+
  2589. +-------+-----+--------------------------------------------------------+
  2590. | p+10  |     | SSAP:  the source SAP obtained from the IEEE 802.2 LLC |
  2591. |       |     | (X'80') subfield in the HPR Capabilities (X'61')       |
  2592. |       |     | control vector in the sent XID3 (see note 4)           |
  2593. +-------+-----+--------------------------------------------------------+
  2594. +-------+-----+--------------------------------------------------------+
  2595. | p+11  |     | Control:                                               |
  2596. +-------+-----+-------+------------------------------------------------+
  2597. |       |     | X'03' | UI with P/F bit off                            |
  2598. +-------+-----+-------+------------------------------------------------+
  2599. +-------+-----+--------------------------------------------------------+
  2600. | p+12-n|     | Remainder of PDU:  NLP                                 |
  2601. +-------+-----+--------------------------------------------------------+
  2602. +-------+-----+--------------------------------------------------------+
  2603. |       |     | Note 1:  Rules for encoding the IP header can be found |
  2604. |       |     | in RFC 791.                                            |
  2605. +-------+-----+--------------------------------------------------------+
  2606. +-------+-----+--------------------------------------------------------+
  2607. |       |     | Note 2:  Rules for encoding the UDP header can be      |
  2608. |       |     | found in RFC 768.                                      |
  2609. +-------+-----+--------------------------------------------------------+
  2610. +----------------------------------------------------------------------+
  2611. | IP Format for NLPs in UI Frames                                      |
  2612. +-------+-----+--------------------------------------------------------+
  2613. | Byte  | Bit | Content                                                |
  2614. +-------+-----+--------------------------------------------------------+
  2615. +-------+-----+--------------------------------------------------------+
  2616. |       |     | Note 3:  The User-Defined Address bit is considered    |
  2617. |       |     | part of the DSAP.  The Individual/Group bit in the     |
  2618. |       |     | DSAP field is set to 0 by the sender and ignored by    |
  2619. |       |     | the receiver.                                          |
  2620. +-------+-----+--------------------------------------------------------+
  2621. +-------+-----+--------------------------------------------------------+
  2622. |       |     | Note 4:  The User-Defined Address bit is considered    |
  2623. |       |     | part of the SSAP.  The Command/Response bit in the     |
  2624. |       |     | SSAP field is set to 0 by the sender and ignored by    |
  2625. |       |     | the receiver.                                          |
  2626. +-------+-----+--------------------------------------------------------+
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634. Dudley                       Informational                     [Page 47]
  2635.  
  2636. RFC 2353                APPN/HPR in IP Networks                 May 1998
  2637.  
  2638.  
  2639. 7.0  Full Copyright Statement
  2640.  
  2641. Copyright (C) The Internet Society (1997).  All Rights Reserved.
  2642.  
  2643. This document and translations of it may be copied and furnished to
  2644. others, and derivative works that comment on or otherwise explain it or
  2645. assist in its implementation may be prepared, copied, published and
  2646. distributed, in whole or in part, without restriction of any kind,
  2647. provided that the above copyright notice and this paragraph are included
  2648. on all such copies and derivative works.  However, this document itself
  2649. may not be modified in any way, such as by removing the copyright notice
  2650. or references to the Internet Society or other Internet organizations,
  2651. except as needed for the purpose of developing Internet standards in
  2652. which case the procedures for copyrights defined in the Internet
  2653. Standards process must be followed, or as required to translate it into
  2654. languages other than English.
  2655.  
  2656. The limited permissions granted above are perpetual and will not be
  2657. revoked by the Internet Society or its successors or assigns.
  2658.  
  2659. This document and the information contained herein is provided on an "AS
  2660. IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
  2661. FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
  2662. LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
  2663. INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
  2664. FITNESS FOR A PARTICULAR PURPOSE.
  2665.  
  2666.  
  2667.  
  2668.  
  2669.  
  2670.  
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676.  
  2677.  
  2678.  
  2679.  
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688.  
  2689.  
  2690. Dudley                       Informational                     [Page 48]
  2691.  
  2692.