⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2353.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 5 页
字号:
   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 CPDudley                       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 TGDudley                       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.Dudley                       Informational                     [Page 16]RFC 2353                APPN/HPR in IP Networks                 May 1998

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -