rfc2353.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          G. Dudley
Request for Comments: 2353                                           IBM
Category: Informational                                         May 1998


                        APPN/HPR in IP Networks
           APPN Implementers' Workshop Closed Pages Document

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

   1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1  Requirements  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.0  IP as a Data Link Control (DLC) for HPR   . . . . . . . . .   3
   2.1  Use of UDP and IP   . . . . . . . . . . . . . . . . . . . .   4
   2.2  Node Structure  . . . . . . . . . . . . . . . . . . . . . .   5
   2.3  Logical Link Control (LLC) Used for IP  . . . . . . . . . .   8
     2.3.1  LDLC Liveness   . . . . . . . . . . . . . . . . . . . .   8
       2.3.1.1  Option to Reduce Liveness Traffic   . . . . . . . .   9
   2.4  IP Port Activation  . . . . . . . . . . . . . . . . . . . .  10
     2.4.1  Maximum BTU Sizes for HPR/IP  . . . . . . . . . . . . .  12
   2.5  IP Transmission Groups (TGs)  . . . . . . . . . . . . . . .  12
     2.5.1  Regular TGs   . . . . . . . . . . . . . . . . . . . . .  12
       2.5.1.1  Limited Resources and Auto-Activation   . . . . . .  19
     2.5.2  IP Connection Networks  . . . . . . . . . . . . . . . .  19
       2.5.2.1  Establishing IP Connection Networks   . . . . . . .  20
       2.5.2.2  IP Connection Network Parameters  . . . . . . . . .  22
       2.5.2.3  Sharing of TGs  . . . . . . . . . . . . . . . . . .  24
       2.5.2.4  Minimizing RSCV Length  . . . . . . . . . . . . . .  25
     2.5.3  XID Changes   . . . . . . . . . . . . . . . . . . . . .  26
     2.5.4  Unsuccessful IP Link Activation   . . . . . . . . . . .  30
   2.6  IP Throughput Characteristics   . . . . . . . . . . . . . .  34
     2.6.1  IP Prioritization   . . . . . . . . . . . . . . . . . .  34
     2.6.2  APPN Transmission Priority and COS  . . . . . . . . . .  36
     2.6.3  Default TG Characteristics  . . . . . . . . . . . . . .  36
     2.6.4  SNA-Defined COS Tables  . . . . . . . . . . . . . . . .  38
     2.6.5  Route Setup over HPR/IP links   . . . . . . . . . . . .  39
     2.6.6  Access Link Queueing  . . . . . . . . . . . . . . . . .  39
   2.7  Port Link Activation Limits   . . . . . . . . . . . . . . .  40



Dudley                       Informational                      [Page 1]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   2.8  Network Management  . . . . . . . . . . . . . . . . . . . .  40
   2.9  IPv4-to-IPv6 Migration  . . . . . . . . . . . . . . . . . .  41
   3.0  References  . . . . . . . . . . . . . . . . . . . . . . . .  42
   4.0  Security Considerations   . . . . . . . . . . . . . . . . .  43
   5.0  Author's Address  . . . . . . . . . . . . . . . . . . . . .  44
   6.0  Appendix - Packet Format  . . . . . . . . . . . . . . . . .  45
   6.1  HPR Use of IP Formats   . . . . . . . . . . . . . . . . . .  45
     6.1.1  IP Format for LLC Commands and Responses  . . . . . . .  45
     6.1.2  IP Format for NLPs in UI Frames   . . . . . . . . . . .  46
   7.0  Full Copyright Statement  . . . . . . . . . . . . . . . . .  48

1.0  Introduction

   The APPN Implementers' Workshop (AIW) is an industry-wide consortium
   of networking vendors that develops Advanced Peer-to-Peer
   Networking(R) (APPN(R)) standards and other standards related to
   Systems Network Architecture (SNA), and facilitates high quality,
   fully interoperable APPN and SNA internetworking products.  The AIW
   approved Closed Pages (CP) status for the architecture in this
   document on December 2, 1997, and, as a result, the architecture was
   added to the AIW architecture of record.  A CP-level document is
   sufficiently detailed that implementing products will be able to
   interoperate; it contains a clear and complete specification of all
   necessary changes to the architecture of record.  However, the AIW
   has procedures by which the architecture may be modified, and the AIW
   is open to suggestions from the internet community.

   The architecture for APPN nodes is specified in "Systems Network
   Architecture Advanced Peer-to-Peer Networking Architecture Reference"
   [1].  A set of APPN enhancements for High Performance Routing (HPR)
   is specified in "Systems Network Architecture Advanced Peer-to-Peer
   Networking High Performance Routing Architecture Reference, Version
   3.0" [2].  The formats associated with these architectures are
   specified in "Systems Network Architecture Formats" [3].  This memo
   assumes the reader is familiar with these specifications.

   This memo defines a method with which HPR nodes can use IP networks
   for communication, and the enhancements to APPN required by this
   method.  This memo also describes an option set that allows the use
   of the APPN connection network model to allow HPR nodes to use IP
   networks for communication without having to predefine link
   connections.

   (R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of
   the IBM Corporation.






Dudley                       Informational                      [Page 2]

RFC 2353                APPN/HPR in IP Networks                 May 1998


1.1  Requirements

   The following are the requirements for the architecture specified in
   this memo:

   1.  Facilitate APPN product interoperation in IP networks by
       documenting agreements such as the choice of the logical link
       control (LLC).

   2.  Reduce system definition (e.g., by extending the connection
       network model to IP networks) -- Connection network support is an
       optional function.

   3.  Use class of service (COS) to retain existing path selection and
       transmission priority services in IP networks; extend
       transmission priority function to include IP networks.

   4.  Allow customers the flexibility to design their networks for low
       cost and high performance.

   5.  Use HPR functions to improve both availability and scalability
       over existing integration techniques such as Data Link Switching
       (DLSw) which is specified in RFC 1795 [4] and RFC 2166 [5].

2.0  IP as a Data Link Control (DLC) for HPR

   This memo specifies the use of IP and UDP as a new DLC that can be
   supported by APPN nodes with the three HPR option sets:  HPR (option
   set 1400), Rapid Transport Protocol (RTP) (option set 1401), and
   Control Flows over RTP (option set 1402).  Logical Data Link Control
   (LDLC) Support (option set 2006) is also a prerequisite.

   RTP is a connection-oriented, full-duplex protocol designed to
   transport data in high-speed networks.  HPR uses RTP connections to
   transport SNA session traffic.  RTP provides reliability (i.e., error
   recovery via selective retransmission), in-order delivery (i.e., a
   first-in-first-out [FIFO] service provided by resequencing data that
   arrives out of order), and adaptive rate-based (ARB) flow/congestion
   control. Because RTP provides these functions on an end-to-end basis,
   it eliminates the need for these functions on the link level along
   the path of the connection.  The result is improved overall
   performance for HPR.  For a more complete description of RTP, see
   Appendix F of [2].

   This new DLC (referred to as the native IP DLC) allows customers to
   take advantage of APPN/HPR functions such as class of service (COS)
   and ARB flow/congestion control in the IP environment.  HPR links
   established over the native IP DLC are referred to as HPR/IP links.



Dudley                       Informational                      [Page 3]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   The following sections describe in detail the considerations and
   enhancements associated with the native IP DLC.

2.1  Use of UDP and IP

   The native IP DLC will use the User Datagram Protocol (UDP) defined
   in RFC 768 [6] and the Internet Protocol (IP) version 4 defined in
   RFC 791 [7].

   Typically, access to UDP is provided by a sockets API.  UDP provides
   an unreliable connectionless delivery service using IP to transport
   messages between nodes.  UDP has the ability to distinguish among
   multiple destinations within a given node, and allows port-number-
   based prioritization in the IP network.  UDP provides detection of
   corrupted packets, a function required by HPR.  Higher-layer
   protocols such as HPR are responsible for handling problems of
   message loss, duplication, delay, out-of-order delivery, and loss of
   connectivity.  UDP is adequate because HPR uses RTP to provide end-
   to-end error recovery and in-order delivery; in addition, LDLC
   detects loss of connectivity.  The Transmission Control Protocol
   (TCP) was not chosen for the native IP DLC because the additional
   services provided by TCP such as error recovery are not needed.
   Furthermore, the termination of TCP connections would require
   additional node resources (control blocks, buffers, timers, and
   retransmit queues) and would, thereby, reduce the scalability of the
   design.

   The UDP header has four two-byte fields.  The UDP Destination Port is
   a 16-bit field that contains the UDP protocol port number used to
   demultiplex datagrams at the destination.  The UDP Source Port is a
   16-bit field that contains the UDP protocol port number that
   specifies the port to which replies should be sent when other
   information is not available.  A zero setting indicates that no
   source port number information is being provided.  When used with the
   native IP DLC, this field is not used to convey a port number for
   replies; moreover, the zero setting is not used.  IANA has registered
   port numbers 12000 through 12004 for use in these two fields by the
   native IP DLC; use of these port numbers allows prioritization in the
   IP network.  For more details of the use of these fields, see 2.6.1,
   "IP Prioritization" on page 28.

   The UDP Checksum is a 16-bit optional field that provides coverage of
   the UDP header and the user data; it also provides coverage of a
   pseudo-header that contains the source and destination IP addresses.
   The UDP checksum is used to guarantee that the data has arrived
   intact at the intended receiver.  When the UDP checksum is set to





Dudley                       Informational                      [Page 4]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   zero, it indicates that the checksum was not calculated and should
   not be checked by the receiver.  Use of the checksum is recommended
   for use with the native IP DLC.

   IP provides an unreliable, connectionless delivery mechanism.  The IP
   protocol defines the basic unit of data transfer through the IP
   network, and performs the routing function (i.e., choosing the path
   over which data will be sent).  In addition, IP characterizes how
   "hosts" and "gateways" should process packets, the circumstances
   under which error messages are generated, and the conditions under
   which packets are discarded.  An IP version 4 header contains an 8-
   bit Type of Service field that specifies how the datagram should be
   handled.  As defined in RFC 1349 [8], the type-of-service byte
   contains two defined fields.  The 3-bit precedence field allows
   senders to indicate the priority of each datagram.  The 4-bit type of
   service field indicates how the network should make tradeoffs between
   throughput, delay, reliability, and cost.  The 8-bit Protocol field
   specifies which higher-level protocol created the datagram.  When
   used with the native IP DLC, this field is set to 17 which indicates
   the higher-layer protocol is UDP.

2.2  Node Structure

   Figure 1 on page 6 shows a possible node functional decomposition for
   transport of HPR traffic across an IP network.  There will be
   variations in different platforms based on platform characteristics.

   The native IP DLC includes a DLC manager, one LDLC component for each
   link, and a link demultiplexor.  Because UDP is a connectionless
   delivery service, there is no need for HPR to activate and deactivate
   lower-level connections.

   The DLC manager activates and deactivates a link demultiplexor for
   each port and an instance of LDLC for each link established in an IP
   network.  Multiple links (e.g., one defined link and one dynamic link
   for connection network traffic) may be established between a pair of
   IP addresses.  Each link is identified by the source and destination
   IP addresses in the IP header and the source and destination service
   access point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0,
   "Appendix - Packet Format" on page 37); the link demultiplexor passes
   incoming packets to the correct instance of LDLC based on these
   identifiers.  Moreover, the IP address pair associated with an active
   link and used in the IP header may not change.

   LDLC also provides other functions (for example, reliable delivery of
   Exchange Identification [XID] commands).  Error recovery for HPR RTP
   packets is provided by the protocols between the RTP endpoints.




Dudley                       Informational                      [Page 5]

RFC 2353                APPN/HPR in IP Networks                 May 1998


   The network control layer (NCL) uses the automatic network routing
   (ANR) information in the HPR network header to either pass incoming
   packets to RTP or an outgoing link.

   All components are shown as single entities, but the number of
   logical instances of each is as follows:

   o   DLC manager -- 1 per node

   o   LDLC -- 1 per link

   o   Link demultiplexor -- 1 per port

   o   NCL -- 1 per node (or 1 per port for efficiency)