📄 rfc2091.txt
字号:
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 + -