rfc2353.txt

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

information:

   o   TG number

   o   VRN CP name

   o   TG characteristics used during route selection

       -   Effective capacity
       -   Cost per connect time
       -   Cost per byte transmitted
       -   Security
       -   Propagation delay
       -   User defined parameters

   o   Signaling information

       -   IP version (indicates the format of the IP header including
           the IP address)

       -   IP address

       -   Link service access point address (LSAP) used for XID, TEST,
           DISC, and DM

2.5.2.2  IP Connection Network Parameters

   For a connection network TG, the parameters are determined by CS
   using several inputs.  Parameters that are particular to the local
   port, connection network, or TG are system defined and received in



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


   DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ).  Signaling
   information for the destination node including its IP address is
   received in the ACTIVATE_ROUTE request from SS.

   The following configuration parameters are received in DEFINE_CN(RQ):

   o   Connection network name (CP name of the VRN)

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

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

   The following configuration parameters are received in
   DEFINE_CN_TG(RQ):

   o   Port name

   o   Connection network name (CP name of the VRN)

   o   Connection network TG number (set to a value between 1 and 239)

   o   TG characteristics (see 2.6.3, "Default TG Characteristics" on
       page 30)

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

   o   Link service access point address (LSAP) used for HPR network
       layer packets (default is X'C8')

   o   Limited resource (default is yes)

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

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

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





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


   o   Shareable with other HPR traffic (default is yes for non-RSVP
       links)

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

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

   The following parameters are received in ACTIVATE_ROUTE for
   connection network TGs:

   o   The TG pair

   o   The destination IP version (if this version is not supported by
       the local node, the ACTIVATE_ROUTE_RSP reports the activation
       failure with sense data X'086B46A5'.)

   o   The destination IP address (in the format specified by the
       destination IP version)

   o   Destination service access point address (DSAP) used for XID,
       TEST, DISC, and DM

2.5.2.3  Sharing of TGs

   Connection network traffic is multiplexed onto a regular defined IP
   TG (usually used for CP-CP session traffic) in order to reduce the
   control block storage.  No XIDs flow to establish a new TG on the IP
   network, and no new LLC is created.  When a regular TG is shared,
   incoming traffic is demultiplexed using the normal means.  If the
   regular TG is deactivated, a path switch is required for the HPR
   connection network traffic sharing the TG.

   Multiplexing is possible if the following conditions hold:

   1.  Both the regular TG and the connection network TG to the VRN are
       defined as shareable between HPR traffic streams.

   2.  The destination IP address is the same.

   3.  The regular TG is established first.  (Because links established
       for connection network traffic do not support CP-CP sessions,
       there is little value in allowing a regular TG to share such a
       link.)

   The destination node is notified via XID when a TG can be shared
   between HPR data streams.  At either end, upon receiving



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


   ACTIVATE_ROUTE requesting a shared TG for connection network traffic,
   CS checks its TGs for one meeting the required specifications before
   initiating a new link.  First, CS looks for a link established for
   the TG pair; if there is no such link, CS determines if there is a
   regular TG that can be shared and, if multiple such TGs exist, which
   TG to choose.  As a result, RTP connections routed over the same TG
   pair may actually use different links, and RTP connections routed
   over different TG pairs may use the same link.

2.5.2.4  Minimizing RSCV Length

   The maximum length of a Route Selection (X'2B') control vector (RSCV)
   is 255 bytes.  Use of connection networks significantly increases the
   size of the RSCV contents required to describe a "hop" across an
   SATF.  First, because two connection network TGs are used to specify
   an SATF hop, two TG Descriptor (X'46') control vectors are required.
   Furthermore, inclusion of DLC signaling information within the TG
   Descriptor control vectors increases the length of these control
   vectors.  As a result, the total number of hops that can be specified
   in RSCVs traversing connection networks is reduced.

   To avoid unnecessarily limiting the number of hops, a primary goal in
   designing the formats for IP signaling information is to minimize
   their size.  Additional techniques are also used to reduce the effect
   of the RSCV length limitation.

   For an IP connection network, DLC signaling information is required
   only for the second TG (i.e., from the VRN to the destination node);
   the signaling information for the first TG is locally defined at the
   origin node.  For this reason, the topology database does not include
   DLC signaling information for the entry describing a connection
   network TG from a network node to a VRN.  The DLC signaling
   information is included in the allied entry for the TG in the
   opposite direction.  This mechanism cannot be used for a connection
   network TG between a VRN and an end node.  However, a node
   implementing IP connection networks does not include IP signaling
   information for the first connection network TG when constructing an
   RSCV.

   In an environment where APPN network nodes are used to route between
   legacy LANs and wide-area IP networks, it is recommended that
   customers not define connection network TGs between these network
   nodes and VRNs representing legacy LANs.  Typically, defined links
   are required between end nodes on the legacy LANs and such network
   nodes which also act as network node servers for the end nodes.
   These defined links can be used for user traffic as well as control
   traffic.  This technique will reduce the number of connection network
   hops in RSCVs between end nodes on different legacy LANs.



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


   Lastly, for environments where RSCVs are still not able to include
   enough hops, extended border nodes (EBNs) can be used to partition
   the network.  In this case, the EBNs will also provide piecewise
   subnet route calculation and RSCV swapping.  Thus, the entire route
   does not need to be described in a single RSCV with its length
   limitation.

2.5.3  XID Changes

   Packets transmitted over IP networks are lost or arrive out of order
   more often than packets transmitted over other "link" technologies.
   As a result, the following problem with the XID3 negotiation protocol
   was exposed:

   --------------------------------------------------------------------

         *---------------------------------*
         |Node A                     Node B|
         *---------------------------------*
                          o
                          o
                          o
                           XID3 (np, NEG)
             o<-------------------------o
             |XID3 (np, SEC)
             *------------------------->o
                          XID3 (np, PRI)|
                        lost<-----------*

           time out
              XID3 (np, SEC)
             o------------------------->o
                               SETMODE  |
             o<-------------------------*
    fail because never
    received XID3 (np, PRI)

   Notation: np  - negotiation proceeding
             NEG - negotiable link station role
             SEC - secondary link station role
             PRI - primary link station role

   --------------------------------------------------------------------
                      Figure 9. XID3 Protocol Problem

   In the above sequence, the XID3(np, PRI), which is a link-level
   response to the received XID3(np, SEC), is lost.  Node A times out
   and resends the XID3(np, SEC) as a link-level command.  When Node B



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


   receives this command, it thinks that the XID3(np, PRI) was
   successfully received by Node A and that the activation XID exchange
   is complete.  As a result, Node B sends SETMODE (SNRM, SABME, or
   XID_DONE_RQ, depending upon the link type).  When Node A receives
   SETMODE, it fails the link activation because it has not received an
   XID3(np, PRI) from Node B confirming that Node B does indeed agree to
   be the primary.  Moreover, there are similar problems with incomplete
   TG number negotiation.

   To solve the problems with incomplete role and TG number negotiation,
   two new indicators are defined in XID3.  The problems are solved only
   if both link stations support these new indicators:

   o   Negotiation Complete Supported indicator (byte 12 bit 0) -- this
       1-bit field indicates whether the Negotiation Complete indicator
       is supported.  This field is meaningful when the XID exchange
       state is negotiation proceeding; otherwise, it is reserved.  A
       value of 0 means the Negotiation Complete indicator is not
       supported; a value of 1 means the indicator is supported.

   o   Negotiation Complete indicator (byte 12 bit 1) -- this 1-bit
       field is meaningful only when the XID exchange state is
       negotiation proceeding, the XID3 is sent by the secondary link
       station, and the Negotiation Complete Supported indicator is set
       to 1; otherwise, this field is reserved.  This field is set to 1
       by a secondary link station that supports enhanced XID
       negotiation when it considers the activation XID negotiation to
       be complete for both link station role and TG number (i.e., it is
       ready to receive a SETMODE command from the primary link
       station.)

   When a primary link station that supports enhanced XID negotiation
   receives an XID3(np) with both the Negotiation Complete Supported
   indicator and the Negotiation Complete indicator set to 1, the
   primary link station will know that it can safely send SETMODE if it
   also considers the XI