rfc2353.txt

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

   o   RTP -- 1 per RTP connection

   o   UDP -- 1 per port

   o   IP -- 1 per port

   Products are free to implement other structures.  Products
   implementing other structures will need to make the appropriate
   modifications to the algorithms and protocol boundaries shown in this
   document.


























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


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

                                         -*
      *-------------*       *-------*     |
      |Configuration|       | Path  |     |
      |   Services  |       |Control|     |
      *-------------*       *-------*     |
            A A                 A         |
            | |                 |         |
            | |                 V         |
            | |              *-----*      | APPN/HPR
            | |              | RTP |      |
            | |              *-----*      |
            | |                 A         |
            | |                 |         |
            | |                 V         |
            | |              *-----*      |
            | |              | NCL |      |
            | |              *-----*      |
            | *------------*    A        -*
            |              |    |
            V              V    V        -*
          *---------*    *---------*      |
          |   DLC   |--->|  LDLC   |      |
          | manager |    |         |      |
          *---------*    *---------*      |
               |              A |         | IP DLC
               *-----------*  | *----*    |
                           V  |      |    |
                         *---------* |    |
                         |  LINK   | |    |
                         |  DEMUX  | |    |
                         *---------* |    |
                              A    *-*   -*
                              |    |
                              |    V
                           *---------*
                           |   UDP   |
                           *---------*
                                A
                                |
                                V
                           *---------*
                           |   IP    |
                           *---------*

   --------------------------------------------------------------------
                      Figure 1. HPR/IP Node Structure



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


2.3  Logical Link Control (LLC) Used for IP

   Logical Data Link Control (LDLC) is used by the native IP DLC.  LDLC
   is defined in [2].  LDLC uses a subset of the services defined by
   IEEE 802.2 LLC type 2 (LLC2).  LDLC uses only the TEST, XID, DISC,
   DM, and UI frames.

   LDLC was defined to be used in conjunction with HPR (with the HPR
   Control Flows over RTP option set 1402) over reliable links that do
   not require link-level error recovery.  Most frame loss in IP
   networks (and the underlying frame networks) is due to congestion,
   not problems with the facilities.  When LDLC is used on a link, no
   link-level error recovery is available; as a result, only RTP traffic
   is supported by the native IP DLC.  Using LDLC eliminates the need
   for LLC2 and its associated cost (adapter storage, longer path
   length, etc.).

2.3.1  LDLC Liveness

   LDLC liveness (using the LDLC TEST command and response) is required
   when the underlying subnetwork does not provide notification of
   connection outage.  Because UDP is connectionless, it does not
   provide outage notification; as a result, LDLC liveness is required
   for HPR/IP links.

   Liveness should be sent periodically on active links except as
   described in the following subsection when the option to reduce
   liveness traffic is implemented.  The default liveness timer period
   is 10 seconds.  When the defaults for the liveness timer and retry
   timer (15 seconds) are used, the period between liveness tests is
   smaller than the time required to detect failure (retry count
   multiplied by retry timer period) and may be smaller than the time
   for liveness to complete successfully (on the order of round-trip
   delay).  When liveness is implemented as specified in the LDLC
   finite-state machine (see [2]) this is not a problem because the
   liveness protocol works as follows:  The liveness timer is for a
   single link.  The timer is started when the link is first activated
   and each time a liveness test completes successfully.  When the timer
   expires, a liveness test is performed.  When the link is operational,
   the period between liveness tests is on the order of the liveness
   timer period plus the round-trip delay.

   For each implementation, it is necessary to check if the liveness
   protocol will work in a satisfactory manner with the default settings
   for the liveness and retry timers.  If, for example, the liveness
   timer is restarted immediately upon expiration, then a different
   default for the liveness timer should be used.




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


2.3.1.1  Option to Reduce Liveness Traffic

   In some environments, it is advantageous to reduce the amount of
   liveness traffic when the link is otherwise idle.  (For example, this
   could allow underlying facilities to be temporarily deactivated when
   not needed.)  As an option, implementations may choose not to send
   liveness when the link is idle (i.e., when data was neither sent nor
   received over the link while the liveness timer was running).  (If
   the implementation is not aware of whether data has been received,
   liveness testing may be stopped while data is not being sent.)
   However, the RTP connections also have a liveness mechanism which
   will generate traffic.  Some implementations of RTP will allow
   setting a large value for the ALIVE timer, thus reducing the amount
   of RTP liveness traffic.

   If LDLC liveness is turned off while the link is idle, one side of
   the link may detect a link failure much earlier than the other.  This
   can cause the following problems:

   o   If a node that is aware of a link failure attempts to reactivate
       the link, the partner node (unaware of the link failure) may
       reject the activation as an unsupported parallel link between the
       two ports.

   o   If a node that is unaware of an earlier link failure sends data
       (including new session activations) on the link, it may be
       discarded by a node that detected the earlier failure and
       deactivated the link.  As a result, session activations would
       fail.

   The mechanisms described below can be used to remedy these problems.
   These mechanisms are needed only in a node not sending liveness when
   the link is idle; thus, they would not be required of a node not
   implementing this option that just happened to be adjacent to a node
   implementing the option.

   o   (Mandatory unless the node supports multiple active defined links
       between a pair of HPR/IP ports and supports multiple active
       dynamic links between a pair of HPR/IP ports.)  Anytime a node
       rejects the activation of an HPR/IP link as an unsupported
       parallel link between a pair of HPR/IP ports (sense data
       X'10160045' or X'10160046'), it should perform liveness on any
       active link between the two ports that is using a different SAP
       pair.  Thus, if the activation was not for a parallel link but
       rather was a reactivation because one of these active links had
       failed, the failed link will be detected.  (If the SAP pair for
       the link being activated matches the SAP pair for an active link,
       a liveness test would succeed because the adjacent node would



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


       respond for the link being activated.)  A simple way to implement
       this function is for LDLC, upon receiving an activation XID, to
       run liveness on all active links with a matching IP address pair
       and a different SAP pair.

   o   (Mandatory) Anytime a node receives an activation XID with an IP
       address pair and a SAP pair that match those of an active link,
       it should deactivate the active link and allow it to be
       reestablished.  A timer is required to prevent stray XIDs from
       deactivating an active link.

   o   (Recommended) A node should attempt to reactivate an HPR/IP link
       before acting on an LDLC-detected failure.  This mechanism is
       helpful in preventing session activation failures in scenarios
       where the other side detected a link failure earlier, but the
       network has recovered.

2.4  IP Port Activation

   The node operator (NO) creates a native IP DLC by issuing
   DEFINE_DLC(RQ) (containing customer-configured parameters) and
   START_DLC(RQ) commands to the node operator facility (NOF).  NOF, in
   turn, passes DEFINE_DLC(RQ) and START_DLC(RQ) signals to
   configuration services (CS), and CS creates the DLC manager.  Then,
   the node operator can define a port by issuing DEFINE_PORT(RQ) (also
   containing customer-configured parameters) to NOF with NOF passing
   the associated signal to CS.

   A node with adapters attached to multiple IP subnetworks may
   represent the multiple adapters as a single HPR/IP port.  However, in
   that case, the node associates a single IP address with that port.
   RFC 1122 [9] requires that a node with multiple adapters be able to
   use the same source IP address on outgoing UDP packets regardless of
   the adapter used for transmission.

















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


     *----------------------------------------------*
     |  NOF                CS                  DLC  |
     *----------------------------------------------*
         . DEFINE_DLC(RQ)   .
   1     o----------------->o
         . DEFINE_DLC(RSP)  |
   2     o<-----------------*
         . START_DLC(RQ)    .      create
   3     o----------------->o------------------->o
         . START_DLC(RSP)   |                    .
   4     o<-----------------*                    .
         . DEFINE_PORT(RQ)  .                    .
   5     o----------------->o                    .
         . DEFINE_PORT(RSP) |                    .
   6     o<-----------------*                    .

             Figure 2. IP Port Activation

   The following parameters are received in DEFINE_PORT(RQ):

   o   Port name

   o   DLC name

   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])