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

📄 rfc2091.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 3 页
字号:
   database is in flux the packet MUST be re-created from the database   to contain only the subset of routes which currently apply.  And if   none of the routes still apply, nothing will be 'retransmitted'.   For simplicity of implementation we would advise having only one   packet in flight.  However if the 'round trip' for a response and   acknowledgement is quite long this could significantly delay large   updates.  See Appendix A for an understanding of the additional   complexity of managing several packets in flight.4. New Packet Types   To support triggered updates, three new packet types MUST be   supported.  For IP RIP Version 1 [1] and IP RIP Version 2 [2] these   are identified by the Command Field values shown:      o  9 - Update Request      o  10 - Update Response      o  11 - Update Acknowledge   For Netware RIP and SAP [3] the equivalent Field to distinguish   between packet types is called Operation and these take the same   values.   These Command and Operation types require the addition of a 4 octet   Update header.  All three packet types contain a Version, which MUST   be 1.  Update Response and Update Acknowledge also have a Sequence   Number and a Flush Flag.Meyer & Sherry              Standards Track                     [Page 8]RFC 2091                      Trigger RIP                   January 19974.1 Update Request   The Update Request has the Command/Operation value 9.   It is a request to the peer system to send ALL appropriate elements   in its routing database.  It is retransmitted at periodic intervals   (every 5 seconds) until an Update Response message is received with   the Flush flag set.   An Update Request is transmitted in the following circumstances:   o  Firstly when the router is powered on.   o  Secondly when the circuit manager indicates a destination has been      in an unreachable (circuit down) state and changes to a reachable      (circuit up) state.   An Update Request may also be sent at other times to compensate for   discarding non-optimal routing information or if an Update Response   continues to be unacknowledged (see section 6.3).4.2 Update Response   The Update Response has the Command/Operation value 10.   It is a message containing zero or more routes in an update.  It is   retransmitted at periodic intervals until an Update Acknowledge is   received.   An Update Response message MUST be sent:   o  In response to an Update Request.  The Update Response MUST have      the Flush flag set.  Other Update Responses should NOT be sent      until an Update Acknowledge has been received acknowledging the      Flush flag.      The remainder of the database MUST then be sent as a series of      Update Responses with the Flush flag NOT set.   o  An Update Response with the Flush flag set MUST also be sent at      power on to flush the peer's routing table learned from a previous      incarnation.  This Update Response SHOULD NOT contain any routes.      This avoids any possibility of an acknowledgement being received      to a response sent BEFORE the unit was restarted causing confusion      about which routes are being acknowledged.   Update Response messages continue to be sent any time there is fresh   routing information to be propagated.Meyer & Sherry              Standards Track                     [Page 9]RFC 2091                      Trigger RIP                   January 1997   Each new Update Response is given a different Sequence Number.  The   Sequence Number only has 'meaning' to the sender of the Update   Response.  The same Update Response sent to different peers MAY have   a different Sequence Number.   An Update Response packet with the Flush flag set MUST be sent to a   peer:      o  At power on.      o  In response to an Update Request packet.      o  After transitioning from a circuit down to a circuit up state.   After sending an Update Flush, the full database MUST be sent   subsequently.4.3 Update Acknowledge   The Update Acknowledge has the Command/Operation value 11.   It is a message sent in response to every Update Response packet   received.  If the Update Response packet has the flush flag set then   so should the Update Acknowledge packet.5. Packet Formats5.1 Update Header   To support the mechanism outlined in this proposal the packet format   for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3]   are modified to include an additional small header when using   Commands Update Request (9), Update Response (10) and Update   Acknowledge (11).  Commands are called Operations in Netware.   Update Request (9):     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  Version (1)  |               must be zero (3)                |     +-------------------------------+-------------------------------+Meyer & Sherry              Standards Track                    [Page 10]RFC 2091                      Trigger RIP                   January 1997     Update Response (10) and Update Acknowledge (11):     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |  Version (1)  |   Flush (1)   |     Sequence Number (2)       |     +-------------------------------+-------------------------------+     Four octet Update headers, with each  tick  mark  representing  one     bit.  All fields are coded in network byte order (big-endian).                         Figure 2.   Update Headers.   Version MUST be 1 in all headers.  Any packets received for a   different Version MUST be silently discarded.   The Sequence Number MUST be incremented every time a new Update   Response packet is sent on the WAN.  The Sequence Number is unchanged   for retransmissions.  The Sequence Number wraps round at 65535.   Flush is set to 1 in an Update Response if the peer is required to   start timing out its entries - otherwise it is set to zero.  Any   other values MUST be silently discarded.   The peer returns an Update Acknowledge containing the same Sequence   Number and Flush.5.2 IP Routing Information Protocol Version 1   IP RIP [1] is a UDP-based protocol which generally sends and receives   datagrams on UDP port number 520.   To support the mechanism outlined in this proposal the packet format   for RIP Version 1 [1] is modified when using Commands Update Request   (9), Update Response (10) and Update Acknowledge (11).  See Figure 3.5.3 IP Routing Information Protocol Version 2   IP RIP Version 2 [2] is an enhancement to IP RIP Version 1 which   allows RIP updates to include subnetting information.   To support the mechanism outlined in this proposal the packet format   for RIP Version 2 [2] is modified when using Commands Update Request   (9), Update Response (10) and Update Acknowledge (11).  See Figure 4.Meyer & Sherry              Standards Track                    [Page 11]RFC 2091                      Trigger RIP                   January 19975.4 Netware Routing Information Protocol   Netware [3] supports a mechanism that allows routers on an   internetwork to exchange routing information using the Routing   Information Protocol (RIP) which runs over the Internetwork Packet   Exchange (IPX) protocol using socket number 453h.   To support the mechanism outlined in this proposal the packet format   for Novell RIP [3] is modified when using Operations Update Request   (9), Update Response (10) and Update Acknowledge (11).  See Figure 5.5.5 Netware Service Advertising Protocol   Netware [3] also supports a mechanism that allows servers on an   internetwork to advertise their services by name and type using the   Service Advertising Protocol (SAP) which runs over the Internetwork   Packet Exchange (IPX) protocol using socket number 452h.  SAP   operates on similar principals to running RIP.  Routers act as SAP   agents, collecting service information from different networks and   relay it to interested parties.   To support the mechanism outlined in this proposal the packet format   for Novell SAP [3] is modified when using Operations Update Request   (9), Update Response (10) and Update Acknowledge (11).  See Figure 6.     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | Command (1)   | RIP Version (1)|     must be zero (2)         |     +---------------+---------------+-------------------------------+     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                     Update Header (4)                         |     +-------------------------------+-------------------------------+Meyer & Sherry              Standards Track                    [Page 12]RFC 2091                      Trigger RIP                   January 1997     Update Response then has up to 25 routing entries (each 20 octets):     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | Address Family Identifier (2) |      must be zero (2)         |     +-------------------------------+-------------------------------+     |                         IP address (4)                        |     +---------------------------------------------------------------+     |                         must be zero (4)                      |     +---------------------------------------------------------------+     |                         must be zero (4)                      |     +---------------------------------------------------------------+     |                         Metric (4)                            |     +---------------------------------------------------------------+                                     .                                     .     The format of an IP RIP datagram in octets,  with  each  tick  mark     representing  one  bit.  All fields are coded in network byte order     (big-endian).     The four octets of the Update header are included in Update Request     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)     packets.  They are not present in packet types in the original  RIP     Version 1 specification.                  Figure 3.   IP RIP Version 1 packet formatMeyer & Sherry              Standards Track                    [Page 13]RFC 2091                      Trigger RIP                   January 1997     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | Command (1)   |RIP Version (1)|      must be zero (2)         |     +---------------+---------------+-------------------------------+     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                     Update Header (4)                         |     +-------------------------------+-------------------------------+     Update Response then has up to 25 routing entries (each 20 octets):     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     | Address Family Identifier (2) |        Route Tag (2)          |     +-------------------------------+-------------------------------+     |                         IP address (4)                        |     +---------------------------------------------------------------+     |                         Subnet Mask (4)                       |     +---------------------------------------------------------------+     |                         Next Hop (4) - must be zero           |     +---------------------------------------------------------------+     |                         Metric (4)                            |     +---------------------------------------------------------------+                                     .                                     .     The format of an IP RIP Version 2 datagram  in  octets,  with  each     tick  mark  representing  one bit.  All fields are coded in network     byte order (big-endian).     The four octets of the Update header are included in Update Request     (Command  9),  Update  Response  (10)  and  Update Acknowledge (11)     Packets.  They are not present in packet types in the original  RIP     Version 2 specification.     Next Hop MUST be zero, since Triggered RIP can NOT advertise routes     on behalf of other WAN routers.     If authentication is used it immediately follows the Update header.                  Figure 4.   IP RIP Version 2 packet formatMeyer & Sherry              Standards Track                    [Page 14]RFC 2091                      Trigger RIP                   January 1997     0                   1         1     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |       Operation (2)           |     +---------------+---------------+     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                     Update Header (4)                         |     +-------------------------------+-------------------------------+     Update Response then has up to 50 routing entries (each 8 octets):     0                   1                   2                   3 3     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                       Network Number (4)                      |     +---------------------------------------------------------------+     |       Number of Hops (2)      |      Number of Ticks (2)      |     +---------------------------------------------------------------+                                     .                                     .     The format of a Netware RIP datagram in octets, with each tick mark     representing  one  bit.  All fields are coded in network byte order     (big-endian).     The four octets of the Update header are included in Update Request     (Operation  9),  Update  Response  (10) and Update Acknowledge (11)     packets.  They are not present in  packet  types  in  the  original     Novell RIP specification.                    Figure 5.   Netware RIP packet format

⌨️ 快捷键说明

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