📄 rfc2961.txt
字号:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a Multicast_Message_Identifier_Tuple consists of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger, et al. Standards Track [Page 21]
RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001
IPv6/MESSAGE_ID MCAST_LIST object
Class = MESSAGE_ID_LIST Class, C_Type = 5
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| IPv6 Multicast_ |
| Message_Identifier_ |
| Tuple |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger, et al. Standards Track [Page 22]
RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001
Where a IPv6 Multicast_Message_Identifier_Tuple consists of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Source_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Destination_IP_Address |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits
No flags are currently defined. This field MUST be zero on
transmission and ignored on receipt.
Epoch: 24 bits
The Epoch field from the MESSAGE_ID object corresponding to the
trigger message that advertised the state being refreshed.
Message_Identifier: 32 bits
The Message_Identifier field from the MESSAGE_ID object
corresponding to the trigger message that advertised the Path
state being refreshed. One or more Message_Identifiers may be
included. Each Message_Identifier MUST be followed by the
source IP address corresponding to the sender of the Path state
being refreshed, and the destination IP address of the session.
Source_IP_Address
The IP address corresponding to the sender of the Path state
being refreshed.
Destination_IP_Address
The destination IP address corresponding to the session of the
Path state being refreshed.
Berger, et al. Standards Track [Page 23]
RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001
5.2. Srefresh Message Format
Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and
MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh
message. MESSAGE_ID SRC_LIST can not be combined in Srefresh
messages with the other objects. A single Srefresh message MAY
refresh both Path and Resv state.
Srefresh messages carrying Message_Identifier fields corresponding to
Path state are normally sent with a destination IP address equal to
the address carried in the corresponding SESSION objects. The
destination IP address MAY be set to the RSVP next hop when the next
hop is known to be RSVP capable and either (a) the session is unicast
or (b) the outgoing interface is a point-to-point link. Srefresh
messages carrying Message_Identifier fields corresponding to Resv
state MUST be sent with a destination IP address set to the Resv
state's previous hop.
Srefresh messages sent to a multicast session's destination IP
address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT
include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects.
Srefresh messages sent to the RSVP next hop MAY contain either or
both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT
include any MESSAGE_ID SRC_LIST objects.
The source IP address of an Srefresh message is an address of the
node that generates the message. The source IP address MUST match
the address associate with the MESSAGE_ID objects when they were
included in a standard RSVP message. As previously mentioned, the
source address associated with a MESSAGE_ID object is represented in
a per RSVP message type specific fashion. For messages with RSVP_HOP
objects, such as Path and Resv messages, the address is found in the
RSVP_HOP object. For other messages, such as ResvConf message, the
associated IP address is the source address in the IP header.
Srefresh messages that are addressed to a session's destination IP
address MUST be sent with the Router Alert IP option in their IP
headers. Srefresh messages addressed directly to RSVP neighbors
SHOULD NOT be sent with the Router Alert IP option in their IP
headers.
Each Srefresh message MUST occupy exactly one IP datagram. If it
exceeds the MTU, the datagram is fragmented by IP and reassembled at
the recipient node. Srefresh messages MAY be sent within an RSVP
Bundle messages. Although this is not expected since Srefresh
Berger, et al. Standards Track [Page 24]
RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001
messages can carry a list of Message_Identifier fields within a
single object. Implementations may choose to limit each Srefresh
message to the MTU size of the outgoing link, e.g., 1500 bytes.
The Srefresh message format is:
<Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<srefresh list> | <source srefresh list>
<srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
[ <srefresh list> ]
<source srefresh list> ::= <MESSAGE_ID SRC_LIST>
[ <source srefresh list> ]
For Srefresh messages, the Msg Type field of the Common Header MUST
be set to 15.
5.3. Srefresh Message Usage
An Srefresh message may be generated to refresh Resv and Path state.
If an Srefresh message is used to refresh some particular state, then
the generation of a standard refresh message for that particular
state SHOULD be suppressed. A state's refresh interval is not
affected by the use of Srefresh message based refreshes.
When generating an Srefresh message, a node SHOULD refresh as much
Path and Resv state as is possible by including the information from
as many MESSAGE_ID objects in the same Srefresh message. Only the
information from MESSAGE_ID objects that meet the source and
destination IP address restrictions, as described in Sections 5.2,
may be included in the same Srefresh message. Identifying Resv state
that can be refreshed using the same Srefresh message is fairly
straightforward. Identifying which Path state may be included is a
little more complex.
Only state that was previously advertised in Path and Resv messages
containing MESSAGE_ID objects can be refreshed via an Srefresh
message. Srefresh message based refreshes must preserve the state
synchronization properties of Path or Resv message based refreshes.
Specifically, the use of Srefresh messages MUST NOT result in state
being timed-out at the RSVP next hop. The period at which state is
refreshed when using Srefresh messages MAY be shorter than the period
that would be used when using Path or Resv message based refreshes,
but it MUST NOT be longer.
Berger, et al. Standards Track [Page 25]
RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001
The particular approach used to trigger Srefresh message based
refreshes is implementation specific. Some possibilities are
triggering Srefresh message generation based on each state's refresh
period or, on a per interface basis, periodically generating Srefresh
messages to refresh all state that has not been refreshed within the
state's refresh interval. Other approaches are also possible. A
default Srefresh message generation interval of 30 seconds is
suggested for nodes that do not dynamically calculate a generation
interval.
When generating an Srefresh message, there are two methods for
identifying which Path state may be refreshed in a specific message.
In both cases, the previously mentioned refresh interval and source
IP address restrictions must be followed. The primary method is to
include only those sessions that share the same destination IP
address in the same Srefresh message.
The secondary method for identifying which Path state may be
refreshed within a single Srefresh message is an optimization. This
method MAY be used when the next hop is known to support RSVP and
when either (a) the session is unicast or (b) the outgoing interface
is a point-to-point link. This method MUST NOT be used when the next
hop is not known to support RSVP or when the outgoing interface is to
a multi-access network and the session is to a multicast address.
The use of this method MAY be administratively configured. When
using this method, the destination address in the IP header of the
Srefresh message is usually the next hop's address. When the use of
this method is administratively configured, the destination address
should be the well known group address 224.0.0.14. When the outgoing
interface is a point-to-point link, all Path state associated with
sessions advertised out the interface SHOULD be included in the same
Srefresh message. When the outgoing interface is not a point-to-
point link, all unicast session Path state SHOULD be included in the
same Srefresh message.
Identifying which Resv state may be refreshed within a single
Srefresh message is based simply on the source and destination IP
addresses. Any state that was previously advertised in Resv messages
with the same IP addresses as an Srefresh message MAY be included.
After identifying the ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -