rfc2353.txt

RFC 的详细文档！

   o   Port type (if IP connection networks are supported, set to shared
       access transport facility [SATF]; otherwise, set to switched)

   o   Link station role (set to negotiable)

   o   Maximum receive BTU size (default is 1461 [1492 less an allowance
       for the IP, UDP, and LLC headers])

   o   Maximum send BTU size (default is 1461 [1492 less an allowance
       for the IP, UDP, and LLC headers])

   o   Link activation limits (total, inbound, and outbound)

   o   IPv4 supported (set to yes)

   o   The local IPv4 address (required if IPv4 is supported)

   o   IPv6 supported (set to no; may be set to yes in the future; see
       2.9, "IPv4-to-IPv6 Migration" on page 35)

   o   The local IPv6 address (required if IPv6 is supported)

   o   Retry count for LDLC (default is 3)




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


   o   Retry timer period for LDLC (default is 15 seconds; a smaller
       value such as 10 seconds can be used for a campus network)

   o   LDLC liveness timer period (default is 10 seconds; see 2.3.1,
       "LDLC Liveness" on page 7)

   o   IP precedence (the setting of the 3-bit field within the Type of
       Service byte of the IP header for the LLC commands such as XID
       and for each of the APPN transmission priorities; the defaults
       are given in 2.6.1, "IP Prioritization" on page 28.)

2.4.1  Maximum BTU Sizes for HPR/IP

   When IP datagrams are larger than the underlying physical links
   support, IP performs fragmentation.  When HPR/IP links are
   established, the default maximum basic transmission unit (BTU) sizes
   are 1461 bytes, which corresponds to the typical IP maximum
   transmission unit (MTU) size of 1492 bytes supported by routers on
   token-ring networks.  1461 is 1492 less 20 bytes for the IP header, 8
   bytes for the UDP header, and 3 bytes for the IEEE 802.2 LLC header.
   The IP header is larger than 20 bytes when optional fields are
   included; smaller maximum BTU sizes should be configured if optional
   IP header fields are used in the IP network.  For IPv6, the default
   is reduced to 1441 bytes to allow for the typical IPv6 header size of
   40 bytes.  Smaller maximum BTU sizes (but not less than 768) should
   be used to avoid fragmentation when necessary.  Larger BTU sizes
   should be used to improve performance when the customer's IP network
   supports a sufficiently large IP MTU size.  The maximum receive and
   send BTU sizes are passed to CS in DEFINE_PORT(RQ).  These maximum
   BTU sizes can be overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ).

   The Flags field in the IP header should be set to allow
   fragmentation.  Some products will not be able to control the setting
   of the bit allowing fragmentation; in that case, fragmentation will
   most likely be allowed.  Although fragmentation is slow and prevents
   prioritization based on UDP port numbers, it does allow connectivity
   across paths with small MTU sizes.

2.5  IP Transmission Groups (TGs)

2.5.1  Regular TGs

   Regular HPR TGs may be established in IP networks using the native IP
   DLC architecture.  Each of these TGs is composed of one or more
   HPR/IP links.  Configuration services (CS) identifies the TG with the
   destination control point (CP) name and TG number; the destination CP





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


   name may be configured or learned via XID, and the TG number, which
   may be configured, is negotiated via XID.  For auto-activatable
   links, the destination CP name and TG number must be configured.

   When multiple links (dynamic or defined) are established between a
   pair of IP ports (each associated with a single IP address), an
   incoming packet can be mapped to its associated link using the IP
   address pair and the service access point (SAP) address pair.  If a
   node receives an activation XID for a defined link with an IP address
   pair and a SAP pair that are the same as for an active defined link,
   that node can assume that the link has failed and that the partner
   node is reactivating the link.  In such a case as an optimization,
   the node receiving the XID can take down the active link and allow
   the link to be reestablished in the IP network.  Because UDP packets
   can arrive out of order, implementation of this optimization requires
   the use of a timer to prevent a stray XID from deactivating an active
   link.

   Support for multiple defined links between a pair of HPR/IP ports is
   optional.  There is currently no value in defining multiple HPR/IP
   links between a pair of ports.  In the future if HPR/IP support for
   the Resource ReSerVation Protocol (RSVP) [10] is defined, it may be
   advantageous to define such parallel links to segregate traffic by
   COS on RSVP "sessions."  Using RSVP, HPR would be able to reserve
   bandwidth in IP networks.  An HPR logical link would be mapped to an
   RSVP "session" that would likely be identified by either a specific
   application-provided UDP port number or a dynamically-assigned UDP
   port number.

   When multiple defined HPR/IP links between ports are not supported,
   an incoming activation for a defined HPR/IP link may be rejected with
   sense data X'10160045' if an active defined HPR/IP link already
   exists between the ports.  If the SAP pair in the activation XID
   matches the SAP pair for the existing link, the optimization
   described above may be used instead.

   If parallel defined HPR/IP links between ports are not supported, an
   incoming activation XID is mapped to the defined link station (if it
   exists) associated with the port on the adjacent node using the
   source IP address in the incoming activation XID.  This source IP
   address should be the same as the destination IP address associated
   with the matching defined link station.  (They may not be the same if
   the adjacent node has multiple IP addresses, and the configuration
   was not coordinated correctly.)

   If parallel HPR/IP links between ports are supported, multiple
   defined link stations may be associated with the port on the adjacent
   node.  In that case, predefined TG numbers (see "Partitioning the TG



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


   Number Space" in Chapter 9 Configuration Services of [1]) may be used
   to map the XID to a specific link station.  However, because the same
   TG characteristics may be used for all HPR/IP links between a given
   pair of ports, all the link stations associated with the port in the
   adjacent node should be equivalent; as a result, TG number
   negotiation using negotiable TG numbers may be used.

   In the future, if multiple HPR/IP links with different
   characteristics are defined between a pair of ports using RSVP,
   defined link stations will need sufficient configured information to
   be matched with incoming XIDs.  (Correct matching of an incoming XID
   to a defined link station allows CS to provide the correct TG
   characteristics to topology and routing services (TRS).)  At that
   time CS will do the mapping based on both the IP address of the
   adjacent node and a predefined TG number.

   The node initiating link activation knows which link it is
   activating.  Some parameters sent in prenegotiation XID are defined
   in the regular link station configuration and not allowed to change
   in following negotiation-proceeding XIDs.  To allow for forward
   migration to RSVP, when a regular TG is activated in an IP network,
   the node receiving the first XID (i.e., the node not initiating link
   activation) must also understand which defined link station is being
   activated before sending a prenegotiation XID in order to correctly
   set parameters that cannot change.  For this reason, the node
   initiating link activation will indicate the TG number in
   prenegotiation XIDs by including a TG Descriptor (X'46') control
   vector containing a TG Identifier (X'80') subfield.  Furthermore, the
   node receiving the first XID will force the node activating the link
   to send the first prenegotiation XID by responding to null XIDs with
   null XIDs.  To prevent potential deadlocks, the node receiving the
   first XID has a limit (the LDLC retry count can be used) on the
   number of null XIDs it will send.  Once this limit is reached, that
   node will send an XID with an XID Negotiation Error (X'22') control
   vector in response to a null XID; sense data X'0809003A' is included
   in the control vector to indicate unexpected null XID.  If the node
   that received the first XID receives a prenegotiation XID without the
   TG Identifier subfield, it will send an XID with an XID Negotiation
   Error control vector to reject the link connection; sense data
   X'088C4680' is included in the control vector to indicate the
   subfield was missing.

   For a regular TG, the TG parameters are provided by the node operator
   based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ).
   The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP
   links:





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


   o   The destination IP host name (this parameter can usually be
       mapped to the destination IP address):  If the link is not
       activated at node initialization, the IP host name should be
       mapped to an IP address, and the IP address should be stored with
       the link station definition.  This is required to allow an
       incoming link activation to be matched with the link station
       definition.  If the adjacent node activates the link with a
       different IP address (e.g., it could have multiple ports), it
       will not be possible to match the link activation with the link
       station definition, and the default parameters specified in the
       local port definition will be used.

   o   The destination IP version (set to version 4, support for version
       6 may be required in the future; this parameter is only required
       if the address and version cannot be determined using the
       destination IP host name.)

   o   The destination IP address (in the format specified by the
       destination IP version; this parameter is only required if the
       address cannot be determined using the destination IP host name.)

   o   Source service access point address (SSAP) used for XID, TEST,
       DISC, and DM (default is X'04'; other values may be specified
       when multiple links between a pair of IP addresses are defined)

   o   Destination service access point address (DSAP) used for XID,
       TEST, DISC, and DM (default is X'04')

   o   Source service access point address (SSAP) used for HPR network
       layer packets (NLPs) (default is X'C8'; other values may be
       specified when multiple links between a pair of IP addresses are
       defined.)

   o   Maximum receive BTU size (default is 1461; this parameter is used
       to override the setting in DEFINE_PORT.)

   o   Maximum send BTU size (default is 1461; this parameter is used to
       override the setting in DEFINE_PORT.)

   o   IP precedence (the setting of the 3-bit field within the Type of
       Service byte of the IP header for LLC commands such as XID and
       for each of the APPN transmission priorities; the defaults are
       given in 2.6.1, "IP Prioritization" on page 28; this parameter is
       used to override the settings in DEFINE_PORT)

   o   Shareable with connection network traffic (default is yes for
       non-RSVP links)




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


   o   Retry count for LDLC (default is 3; this parameter is used to
       override the setting in DEFINE_PORT)

   o   Retry timer period for LDLC (default is 15 seconds; a smaller
       value such as 10 seconds can be used for a campus link; this
       parameter is used to override the setting in DEFINE_PORT)

   o   LDLC liveness timer period (default is 10 seconds; this parameter
       is to override the setting in DEFINE_PORT; see 2.3.1, "LDLC ness"
       on page 7)

   o   Auto-activation supported (default is no; may be set to yes when
       the local node has switched access to the IP network)

   o   Limited resource (default is to set in concert with auto-
       activation supported)

   o   Limited resource liveness timer (default is 45 sec.)

   o   Port name

   o   Adjacent CP name (optional)

   o   Local CP-CP sessions supported

   o   Defined TG number (optional)

   o   TG characteristics

   The following figures show the activation and deactivation of regular
   TGs.