RFC5063 日本語訳
5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) GracefulRestart. A. Satyanarayana, Ed., R. Rahman, Ed.. October 2007. (Format: TXT=58542 bytes) (Updates RFC2961, RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Satyanarayana, Ed. Request for Comments: 5063 R. Rahman, Ed. Updates: 2961, 3473 Cisco Systems Category: Standards Track October 2007
Network Working Group A. Satyanarayana, Ed. Request for Comments: 5063 R. Rahman, Ed. Updates: 2961, 3473 Cisco Systems Category: Standards Track October 2007
Extensions to GMPLS Resource Reservation Protocol (RSVP)
Graceful Restart
Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
Abstract
This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.
This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs).
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs).
Satyanarayana & Rahman Standards Track [Page 1] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 1] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Terminology .....................................................5
4. Extensions to Nodal Fault Handling ..............................5
4.1. RecoveryPath Message Format ................................5
4.2. Capability Object ..........................................6
4.2.1. Conformance .........................................7
4.3. Related Procedures .........................................7
4.4. Procedures for the Capability Object .......................8
4.4.1. Procedures for the Downstream Neighbor ..............8
4.4.2. Procedures for the Restarting Node ..................8
4.5. Procedures for the RecoveryPath Message ....................9
4.5.1. Procedures for the Downstream Neighbor ..............9
4.5.2. Procedures for the Restarting Node .................10
4.5.2.1. Path and RecoveryPath Message Procedures ..11
4.5.2.2. Re-Synchronization Procedures .............12
4.5.2.3. Procedures on Expiration of
Recovery Period ...........................13
4.6. Compatibility .............................................13
5. RecoveryPath Summary Refresh ...................................14
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
5.2. RecoveryPath Srefresh Capable Bit .........................16
5.2.1. Procedures .........................................16
5.2.2. Compatibility ......................................17
5.3. RecoveryPath Summary Refresh Procedures ...................17
5.3.1. Generation of RecoveryPath-Related Srefresh
Messages ...........................................17
5.3.2. RecoveryPath-Related Srefresh Receive
Processing and NACK Generation .....................19
5.3.3. RecoveryPath-Related MESSAGE_ID NACK
Receive Processing .................................19
6. Security Considerations ........................................20
7. Acknowledgments ................................................21
8. IANA Considerations ............................................21
9. Normative References ...........................................22
1. Introduction ....................................................3 2. Conventions Used in This Document ...............................5 3. Terminology .....................................................5 4. Extensions to Nodal Fault Handling ..............................5 4.1. RecoveryPath Message Format ................................5 4.2. Capability Object ..........................................6 4.2.1. Conformance .........................................7 4.3. Related Procedures .........................................7 4.4. Procedures for the Capability Object .......................8 4.4.1. Procedures for the Downstream Neighbor ..............8 4.4.2. Procedures for the Restarting Node ..................8 4.5. Procedures for the RecoveryPath Message ....................9 4.5.1. Procedures for the Downstream Neighbor ..............9 4.5.2. Procedures for the Restarting Node .................10 4.5.2.1. Path and RecoveryPath Message Procedures ..11 4.5.2.2. Re-Synchronization Procedures .............12 4.5.2.3. Procedures on Expiration of Recovery Period ...........................13 4.6. Compatibility .............................................13 5. RecoveryPath Summary Refresh ...................................14 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15 5.2. RecoveryPath Srefresh Capable Bit .........................16 5.2.1. Procedures .........................................16 5.2.2. Compatibility ......................................17 5.3. RecoveryPath Summary Refresh Procedures ...................17 5.3.1. Generation of RecoveryPath-Related Srefresh Messages ...........................................17 5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK Generation .....................19 5.3.3. RecoveryPath-Related MESSAGE_ID NACK Receive Processing .................................19 6. Security Considerations ........................................20 7. Acknowledgments ................................................21 8. IANA Considerations ............................................21 9. Normative References ...........................................22
Satyanarayana & Rahman Standards Track [Page 2] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 2] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
1. Introduction
1. Introduction
RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms defined in [RFC3209]. When data/forwarding plane state can be retained across the restart of the RSVP agent that established such state, RSVP Graceful Restart provides the ability for the RSVP agent to resynchronize its state based on updates received from its neighboring RSVP agents, and, reconcile such state with the retained data/forwarding plane state. [RFC3209] describes a mechanism, using RSVP Hello messages, to detect the state of an adjacent RSVP agent. [RFC3473] extends this mechanism to advertise the capability of retaining data/forwarding plane state across the restart of a node or a "nodal fault". [RFC3473] also defines the Recovery Label object for use in the Path message of the RSVP neighbor upstream of a restarting node, to indicate that the Path message is for existing data plane state.
RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms defined in [RFC3209]. When data/forwarding plane state can be retained across the restart of the RSVP agent that established such state, RSVP Graceful Restart provides the ability for the RSVP agent to resynchronize its state based on updates received from its neighboring RSVP agents, and, reconcile such state with the retained data/forwarding plane state. [RFC3209] describes a mechanism, using RSVP Hello messages, to detect the state of an adjacent RSVP agent. [RFC3473] extends this mechanism to advertise the capability of retaining data/forwarding plane state across the restart of a node or a "nodal fault". [RFC3473] also defines the Recovery Label object for use in the Path message of the RSVP neighbor upstream of a restarting node, to indicate that the Path message is for existing data plane state.
This document presents extensions to address two aspects of graceful restart not previously supported. The presented extensions enable a restarting node to recover all objects in previously transmitted Path messages, including the Explicit Route Object (ERO), from its downstream neighbors, thus recovering the control plane state. The extensions do not facilitate the recovery or creation of data/forwarding plane state, and can only be used to reestablish control plane state that matches in-place data/forwarding state. The extensions also enable graceful restart of an ingress node that does not preserve full RSVP state across restarts. The presented extensions are equally applicable to LSPs of various switching types as defined in [RFC3471].
This document presents extensions to address two aspects of graceful restart not previously supported. The presented extensions enable a restarting node to recover all objects in previously transmitted Path messages, including the Explicit Route Object (ERO), from its downstream neighbors, thus recovering the control plane state. The extensions do not facilitate the recovery or creation of data/forwarding plane state, and can only be used to reestablish control plane state that matches in-place data/forwarding state. The extensions also enable graceful restart of an ingress node that does not preserve full RSVP state across restarts. The presented extensions are equally applicable to LSPs of various switching types as defined in [RFC3471].
Per [RFC3473], a restarting node can distinguish Path messages associated with LSPs being recovered by the presence of the Recovery Label object. To determine the downstream (outgoing) interface and associated label(s), the restarting node must consult the data plane. This may not be possible for all types of nodes. Furthermore, data plane information is not sufficient to reconstruct all previously transmitted Path state. In these cases, the only source of RSVP state is the downstream RSVP neighbor.
Per [RFC3473], a restarting node can distinguish Path messages associated with LSPs being recovered by the presence of the Recovery Label object. To determine the downstream (outgoing) interface and associated label(s), the restarting node must consult the data plane. This may not be possible for all types of nodes. Furthermore, data plane information is not sufficient to reconstruct all previously transmitted Path state. In these cases, the only source of RSVP state is the downstream RSVP neighbor.
For example, when the restarting node is an ingress node, all previously transmitted Path state may need to be recovered. Such Path state may include (but is not restricted to) the Protection object, the Admin Status object, the Session Attribute object, the Notify Request object, and the Sender Tspec object. A restarting transit node may have modified received Path state in its previously transmitted Path message, which cannot be reconstructed internally during recovery.
For example, when the restarting node is an ingress node, all previously transmitted Path state may need to be recovered. Such Path state may include (but is not restricted to) the Protection object, the Admin Status object, the Session Attribute object, the Notify Request object, and the Sender Tspec object. A restarting transit node may have modified received Path state in its previously transmitted Path message, which cannot be reconstructed internally during recovery.
Satyanarayana & Rahman Standards Track [Page 3] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 3] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Another example of state that cannot be completely recovered from the data plane in some cases is the previously transmitted ERO. Recovery of the previously transmitted ERO minimizes subsequent change of downstream LSP state. On a restarting ingress node, the ERO may have been based on configuration or the result of a previous path computation. A restarting transit node may have previously performed some form of path computation as a result of not receiving an ERO or receiving a loose hop in the ERO. In addition to the ERO, the restarting node may have modified other received Path state in its previously transmitted Path state, which cannot be reconstructed internally during recovery.
Another example of state that cannot be completely recovered from the data plane in some cases is the previously transmitted ERO. Recovery of the previously transmitted ERO minimizes subsequent change of downstream LSP state. On a restarting ingress node, the ERO may have been based on configuration or the result of a previous path computation. A restarting transit node may have previously performed some form of path computation as a result of not receiving an ERO or receiving a loose hop in the ERO. In addition to the ERO, the restarting node may have modified other received Path state in its previously transmitted Path state, which cannot be reconstructed internally during recovery.
The defined extensions provide a restarting upstream node with all information previously transmitted by the node in Path messages. This is accomplished by the downstream RSVP neighbor sending a new message for every Path message it has previously received from the restarting node, after reestablishing RSVP communication with a restarted node that supports the recovery procedures defined in Section 4.5.2 of this document.
The defined extensions provide a restarting upstream node with all information previously transmitted by the node in Path messages. This is accomplished by the downstream RSVP neighbor sending a new message for every Path message it has previously received from the restarting node, after reestablishing RSVP communication with a restarted node that supports the recovery procedures defined in Section 4.5.2 of this document.
The new message is called the RecoveryPath message. The message conveys the contents of the last received Path message back to the restarting node. The restarting node can use the RecoveryPath message, along with the state in the received Path message to associate control and data plane state and to validate the forwarding state with the state presented by the neighboring RSVP nodes.
The new message is called the RecoveryPath message. The message conveys the contents of the last received Path message back to the restarting node. The restarting node can use the RecoveryPath message, along with the state in the received Path message to associate control and data plane state and to validate the forwarding state with the state presented by the neighboring RSVP nodes.
The restarting node indicates its desire to receive and process the RecoveryPath message by including a new object called the Capability object with the RecoveryPath Desired bit set, in its Hello messages sent to the downstream RSVP neighbor. The downstream RSVP neighbor can indicate its ability to send RecoveryPath messages by including the Capability object with the RecoveryPath Transmit Enabled set in its Hello messages to the restarting node. Thus, both the restarting node and its RSVP neighbor, with the help of the Capability object, can detect if the RecoveryPath message extensions defined in this document can be used to recover signaling state after a restart.
The restarting node indicates its desire to receive and process the RecoveryPath message by including a new object called the Capability object with the RecoveryPath Desired bit set, in its Hello messages sent to the downstream RSVP neighbor. The downstream RSVP neighbor can indicate its ability to send RecoveryPath messages by including the Capability object with the RecoveryPath Transmit Enabled set in its Hello messages to the restarting node. Thus, both the restarting node and its RSVP neighbor, with the help of the Capability object, can detect if the RecoveryPath message extensions defined in this document can be used to recover signaling state after a restart.
If the restarting node is a transit node, it will receive a Path message with a Recovery Label object from its upstream RSVP neighbor. In addition, the RecoveryPath message allows such transit nodes to reconstruct any state that was previously dynamically constructed by the node, e.g., ERO sub-objects. If the restarting node is an ingress node, all significant signaling state can be recovered based on the RecoveryPath message.
If the restarting node is a transit node, it will receive a Path message with a Recovery Label object from its upstream RSVP neighbor. In addition, the RecoveryPath message allows such transit nodes to reconstruct any state that was previously dynamically constructed by the node, e.g., ERO sub-objects. If the restarting node is an ingress node, all significant signaling state can be recovered based on the RecoveryPath message.
Satyanarayana & Rahman Standards Track [Page 4] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 4] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Selective transmission of the RecoveryPath message is supported by enhancing the Summary Refresh mechanisms defined in [RFC2961]. When Recovery Summary Refresh is supported, the restarting node can select the LSPs for which it would like to receive RecoveryPath messages. This is useful when the restarting node is able to locally recover the signaling state for a subset of the previously active LSPs.
Selective transmission of the RecoveryPath message is supported by enhancing the Summary Refresh mechanisms defined in [RFC2961]. When Recovery Summary Refresh is supported, the restarting node can select the LSPs for which it would like to receive RecoveryPath messages. This is useful when the restarting node is able to locally recover the signaling state for a subset of the previously active LSPs.
Restarting egress nodes, and Resv message processing are not impacted by the presented extensions, see [RFC3473] for details.
Restarting egress nodes, and Resv message processing are not impacted by the presented extensions, see [RFC3473] for details.
2. Conventions Used in This Document
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
3. Terminology
3. Terminology
The reader is assumed to be familiar with the terminology defined in [RFC3209] and [RFC3473].
The reader is assumed to be familiar with the terminology defined in [RFC3209] and [RFC3473].
Throughout this document, the term "node", when used in the context of a restarting or restarted node, generally refers to the control plane component, which is the signaling controller for a data plane switch.
Throughout this document, the term "node", when used in the context of a restarting or restarted node, generally refers to the control plane component, which is the signaling controller for a data plane switch.
4. Extensions to Nodal Fault Handling
4. Extensions to Nodal Fault Handling
This section presents the protocol modifications to Section 9 of [RFC3473].
This section presents the protocol modifications to Section 9 of [RFC3473].
4.1. RecoveryPath Message Format
4.1. RecoveryPath Message Format
The format of a RecoveryPath message is the same as the format of a Path message, as defined in [RFC3473], but uses a new message number (30) so that it can be identified correctly.
The format of a RecoveryPath message is the same as the format of a Path message, as defined in [RFC3473], but uses a new message number (30) so that it can be identified correctly.
<RecoveryPath Message> ::= <Path Message>
<RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node. Except as specified below, all objects in a RecoveryPath message are identical to the objects in the corresponding Path message last received by the sending node.
The destination address used in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node. Except as specified below, all objects in a RecoveryPath message are identical to the objects in the corresponding Path message last received by the sending node.
Satyanarayana & Rahman Standards Track [Page 5] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 5] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
4.2. Capability Object
4.2. Capability Object
Capability objects are carried in RSVP Hello messages. The Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type of 1.
Capability objects are carried in RSVP Hello messages. The Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type of 1.
The message format of a Hello message is modified to be:
The message format of a Hello message is modified to be:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ]
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> [ <RESTART_CAP> ] [ <CAPABILITY> ]
The format of a Capability object is:
The format of a Capability object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(134)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |T|R|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Transmit Enabled (T): 1 bit
RecoveryPath Transmit Enabled (T): 1 bit
When set (1), indicates that the sending node is enabled to
send RecoveryPath messages. Absence of the Capability object
MUST be treated as if the T-bit is cleared (0).
When set (1), indicates that the sending node is enabled to send RecoveryPath messages. Absence of the Capability object MUST be treated as if the T-bit is cleared (0).
RecoveryPath Desired (R): 1 bit
RecoveryPath Desired (R): 1 bit
When set (1), indicates that the sending node desires to
receive RecoveryPath messages. Absence of the Capability
object MUST be treated as if the R-bit is cleared (0).
When set (1), indicates that the sending node desires to receive RecoveryPath messages. Absence of the Capability object MUST be treated as if the R-bit is cleared (0).
RecoveryPath Srefresh Capable (S): 1 bit
RecoveryPath Srefresh Capable (S): 1 bit
When set (1), along with the R-bit, indicates that the sending
node is capable of receiving and processing Srefresh messages
with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST
object. Absence of the Capability object MUST be treated as if
the S-bit is cleared (0). Related procedures are defined in
Section 5.2.1.
When set (1), along with the R-bit, indicates that the sending node is capable of receiving and processing Srefresh messages with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST object. Absence of the Capability object MUST be treated as if the S-bit is cleared (0). Related procedures are defined in Section 5.2.1.
Reserved bits
Reserved bits
Reserved bits MUST be set to zero on transmission and MUST be
ignored on receipt.
Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt.
Satyanarayana & Rahman Standards Track [Page 6] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 6] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
4.2.1. Conformance
4.2.1. Conformance
All nodes supporting the extensions defined in this document MUST be able to transmit, and properly receive and process RecoveryPath messages. All nodes MUST be able to set both the T and R bits. Both the T and R bits SHOULD be set (1) by default. A node MAY allow RecoveryPath message transmission and reception to be independently disabled based on local policy. When RecoveryPath message transmission is disabled, the T-bit MUST be set to zero (0). When RecoveryPath message reception is not desired, the R-bit MUST be set to zero (0).
All nodes supporting the extensions defined in this document MUST be able to transmit, and properly receive and process RecoveryPath messages. All nodes MUST be able to set both the T and R bits. Both the T and R bits SHOULD be set (1) by default. A node MAY allow RecoveryPath message transmission and reception to be independently disabled based on local policy. When RecoveryPath message transmission is disabled, the T-bit MUST be set to zero (0). When RecoveryPath message reception is not desired, the R-bit MUST be set to zero (0).
Any node that supports the extensions defined in this document and sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support setting of the S-bit and support the mechanisms defined in Section 5.
Any node that supports the extensions defined in this document and sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support setting of the S-bit and support the mechanisms defined in Section 5.
4.3. Related Procedures
4.3. Related Procedures
This document does not modify existing procedures for sending and receiving RSVP Hello messages, as defined in [RFC3209], and the Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. The procedures for control channel faults are defined in [RFC3473] and are not changed by this document.
This document does not modify existing procedures for sending and receiving RSVP Hello messages, as defined in [RFC3209], and the Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. The procedures for control channel faults are defined in [RFC3473] and are not changed by this document.
The presented extensions require the use of RSVP Hellos, as defined in [RFC3209], and the use of the Restart_Cap object extension as defined in [RFC3473]. The presented extensions address only "Nodal Faults" as defined in [RFC3473]. Control channel faults are fully addressed in [RFC3473].
The presented extensions require the use of RSVP Hellos, as defined in [RFC3209], and the use of the Restart_Cap object extension as defined in [RFC3473]. The presented extensions address only "Nodal Faults" as defined in [RFC3473]. Control channel faults are fully addressed in [RFC3473].
Note: There are no changes to the procedures defined in Section 9.5.3 in [RFC3473] (Procedures for the Neighbor of a Restarting node). There are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
Note: There are no changes to the procedures defined in Section 9.5.3 in [RFC3473] (Procedures for the Neighbor of a Restarting node). There are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
There are no changes to the procedures with respect to the data/forwarding plane as described in [RFC3473]. In particular, a restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document.
There are no changes to the procedures with respect to the data/forwarding plane as described in [RFC3473]. In particular, a restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document.
The following sections assume previously defined procedures are followed, except where explicitly modified.
The following sections assume previously defined procedures are followed, except where explicitly modified.
Satyanarayana & Rahman Standards Track [Page 7] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 7] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
4.4. Procedures for the Capability Object
4.4. Procedures for the Capability Object
4.4.1. Procedures for the Downstream Neighbor
4.4.1. Procedures for the Downstream Neighbor
If a node is capable of sending RecoveryPath messages, it MUST include the Capability object with the RecoveryPath Transmit Enabled (T) bit set (1) in all its Hello messages.
If a node is capable of sending RecoveryPath messages, it MUST include the Capability object with the RecoveryPath Transmit Enabled (T) bit set (1) in all its Hello messages.
If the downstream RSVP neighbor receives Hello messages from a restarting node, with the Restart_Cap object, as defined in [RFC3473], and with the Capability object with the RecoveryPath Desired (R) bit set (1), it MUST treat the restarting node as capable of receiving and processing RecoveryPath messages as defined in this document.
If the downstream RSVP neighbor receives Hello messages from a restarting node, with the Restart_Cap object, as defined in [RFC3473], and with the Capability object with the RecoveryPath Desired (R) bit set (1), it MUST treat the restarting node as capable of receiving and processing RecoveryPath messages as defined in this document.
If the downstream RSVP neighbor receives a Capability object in a Hello message with the RecoveryPath Desired (R) bit set (1), but without the Restart_Cap object, it MUST process the Hello message as if the RecoveryPath Receive Desired (R) bit is cleared (0) in the Hello message.
If the downstream RSVP neighbor receives a Capability object in a Hello message with the RecoveryPath Desired (R) bit set (1), but without the Restart_Cap object, it MUST process the Hello message as if the RecoveryPath Receive Desired (R) bit is cleared (0) in the Hello message.
If the downstream RSVP neighbor does not receive the Capability object in Hello messages sent by the restarting node or the RecoveryPath Desired (R) bit is cleared (0) in the Capability object, it MUST treat the restarting node as not capable of supporting the RecoveryPath message procedures defined in this document, and MUST revert to recovery procedures as defined in [RFC3473].
If the downstream RSVP neighbor does not receive the Capability object in Hello messages sent by the restarting node or the RecoveryPath Desired (R) bit is cleared (0) in the Capability object, it MUST treat the restarting node as not capable of supporting the RecoveryPath message procedures defined in this document, and MUST revert to recovery procedures as defined in [RFC3473].
4.4.2. Procedures for the Restarting Node
4.4.2. Procedures for the Restarting Node
A node that expects to recover RSVP state by the receipt and processing of RecoveryPath messages according to procedures defined in this document, MUST include the Capability object with the RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to its neighbors. The node MUST also include the Restart_Cap object, as defined in [RFC3473], in all those Hello messages.
A node that expects to recover RSVP state by the receipt and processing of RecoveryPath messages according to procedures defined in this document, MUST include the Capability object with the RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to its neighbors. The node MUST also include the Restart_Cap object, as defined in [RFC3473], in all those Hello messages.
If the Recovery Time is zero (0) or the restarting node does not support/desire the use of RecoveryPath messages, the RecoveryPath Desired (R) bit MUST be cleared (0) in the Capability object included in Hello messages, or the Capability object MAY be omitted from Hello messages sent by the restarting node.
If the Recovery Time is zero (0) or the restarting node does not support/desire the use of RecoveryPath messages, the RecoveryPath Desired (R) bit MUST be cleared (0) in the Capability object included in Hello messages, or the Capability object MAY be omitted from Hello messages sent by the restarting node.
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit set (1) in the Capability object and the Restart_Cap object, as defined in [RFC3473], it MUST treat the downstream RSVP neighbor as capable of sending RecoveryPath messages
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit set (1) in the Capability object and the Restart_Cap object, as defined in [RFC3473], it MUST treat the downstream RSVP neighbor as capable of sending RecoveryPath messages
Satyanarayana & Rahman Standards Track [Page 8] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 8] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
according to procedures defined in Section 4.5.1. If the restarting node expects to recover RSVP state by the receipt and processing of RecoveryPath messages, it MUST follow procedures defined in Section 4.5.2, with the downstream RSVP neighbor.
according to procedures defined in Section 4.5.1. If the restarting node expects to recover RSVP state by the receipt and processing of RecoveryPath messages, it MUST follow procedures defined in Section 4.5.2, with the downstream RSVP neighbor.
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit cleared (0) in the Capability object, or, with the Capability object not present, it MUST treat the downstream RSVP neighbor as not capable of the RecoveryPath message procedures defined in this document, and, it MUST revert to the recovery procedures defined in [RFC3473] immediately, with the downstream RSVP neighbor.
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit cleared (0) in the Capability object, or, with the Capability object not present, it MUST treat the downstream RSVP neighbor as not capable of the RecoveryPath message procedures defined in this document, and, it MUST revert to the recovery procedures defined in [RFC3473] immediately, with the downstream RSVP neighbor.
4.5. Procedures for the RecoveryPath Message
4.5. Procedures for the RecoveryPath Message
4.5.1. Procedures for the Downstream Neighbor
4.5.1. Procedures for the Downstream Neighbor
After a downstream RSVP neighbor has detected that its upstream node has restarted, is capable of recovery as defined in [RFC3473], and, is capable of receiving RecoveryPath messages as defined in Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message. During the Recovery Period, if the downstream RSVP neighbor detects that the restarting node is not capable of receiving RecoveryPath messages by the absence of the Capability object or the RecoveryPath Desired (R) bit cleared (0) in the Capability object in the restarting node's Hello messages, the downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to the restarting node.
After a downstream RSVP neighbor has detected that its upstream node has restarted, is capable of recovery as defined in [RFC3473], and, is capable of receiving RecoveryPath messages as defined in Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message. During the Recovery Period, if the downstream RSVP neighbor detects that the restarting node is not capable of receiving RecoveryPath messages by the absence of the Capability object or the RecoveryPath Desired (R) bit cleared (0) in the Capability object in the restarting node's Hello messages, the downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to the restarting node.
The RecoveryPath message is constructed by copying all objects from the last received associated Path message, with the following exceptions:
The RecoveryPath message is constructed by copying all objects from the last received associated Path message, with the following exceptions:
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not
copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK
objects used in RecoveryPath messages are generated based on
procedures defined in [RFC2961].
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects used in RecoveryPath messages are generated based on procedures defined in [RFC2961].
The Integrity object is not copied. Any Integrity objects used in
RecoveryPath messages are generated based on procedures defined in
[RFC2747].
The Integrity object is not copied. Any Integrity objects used in RecoveryPath messages are generated based on procedures defined in [RFC2747].
The RSVP Hop object is copied from the most recent associated Resv
message sent to the restarted node for the LSP being recovered.
The RSVP Hop object is copied from the most recent associated Resv message sent to the restarted node for the LSP being recovered.
Satyanarayana & Rahman Standards Track [Page 9] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
Satyanarayana & Rahman Standards Track [Page 9] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
In the sender descriptor, the Recovery Label object MUST be
included, with the label value copied from the label value in the
Label object in the most recent associated Resv message sent to
the restarted node, for the LSP being recovered.
In the sender descriptor, the Recovery Label object MUST be included, with the label value copied from the label value in the Label object in the most recent associated Resv message sent to the restarted node, for the LSP being recovered.
All other objects from the most recent received Path message MUST be included in the RecoveryPath message.
All other objects from the most recent received Path message MUST be included in the RecoveryPath message.
All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If there are many LSPs to be recovered by the restarted node, the downstream RSVP neighbor should avoid sending RecoveryPath messages in a short time interval to avoid overloading the restarted node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval. The range of Recovery Time is dependent on many factors including, but not limited to, the CPU processing power on the restarting node as well as the upstream and downstream neighbors, the amount of CPU available for processing RSVP recovery procedures, and the implementation specifics that affect the amount of time taken to verify the received recovery state against existing forwarding plane state. Such discussion is out of scope of this document.
All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If there are many LSPs to be recovered by the restarted node, the downstream RSVP neighbor should avoid sending RecoveryPath messages in a short time interval to avoid overloading the restarted node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval. The range of Recovery Time is dependent on many factors including, but not limited to, the CPU processing power on the restarting node as well as the upstream and downstream neighbors, the amount of CPU available for processing RSVP recovery procedures, and the implementation specifics that affect the amount of time taken to verify the received recovery state against existing forwarding plane state. Such discussion is out of scope of this document.
After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically resend the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message for the LSP the RecoveryPath message represents. Each such resend attempt is at the end of any Message ID rapid retransmissions, if the Message ID mechanism is used. If the Message ID mechanism is not in use, the period between resend attempts SHOULD be such that at least 3 attempts are completed before the expiry of 3/4 the Recovery Time interval. Each such resend attempt MUST treat the RecoveryPath message as a new message and update the MESSAGE_ID object according to procedures defined in [RFC2961]. Note, per [RFC3473], Resv messages are suppressed during this recovery period until a corresponding Path message is received.
After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically resend the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message for the LSP the RecoveryPath message represents. Each such resend attempt is at the end of any Message ID rapid retransmissions, if the Message ID mechanism is used. If the Message ID mechanism is not in use, the period between resend attempts SHOULD be such that at least 3 attempts are completed before the expiry of 3/4 the Recovery Time interval. Each such resend attempt MUST treat the RecoveryPath message as a new message and update the MESSAGE_ID object according to procedures defined in [RFC2961]. Note, per [RFC3473], Resv messages are suppressed during this recovery period until a corresponding Path message is received.
4.5.2. Procedures for the Restarting Node
4.5.2. Procedures for the Restarting Node
These procedures apply during the "state recovery process" and "Recovery Period" as defined in Section 9.5.2 of [RFC3473]. Any RecoveryPath message received after the Recovery Period has expired SHOULD be matched against local LSP state. If matching fully resynchronized state is located, the node SHOULD send a Path message downstream. If non-resynchronized or no LSP state matching the RecoveryPath message is located, the restarted node MAY send a PathTear message constructed from the RecoveryPath message to
これらの手順は「州の回復の過程」と「回復の期間」の間、.2セクション9.5[RFC3473]で定義されるように適用されます。 満期のSHOULDがRecovery Periodが地方のLSP状態に取り組ませた後にどんなRecoveryPathメッセージも受信されました。 合っている完全に再連動している状態が見つけられているなら、ノードSHOULDはPathメッセージを川下に送ります。 非再連動するかいいえ、LSPがマッチングを述べるなら、RecoveryPathメッセージは見つけられています、ノードがRecoveryPathメッセージから構成されたPathTearメッセージを送るかもしれない再開
Satyanarayana & Rahman Standards Track [Page 10] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[10ページ]RFC5063GMPLS RSVP
expedite the cleanup of unrecovered RSVP and associated forwarding state downstream of the restarted node. The restarting node MUST NOT create data plane or forwarding state to match the received RecoveryPath message.
unrecovered RSVPのクリーンアップと再開しているノードの関連推進州の川下を速めてください。 再開ノードは、受信されたRecoveryPathメッセージを合わせるためにデータ飛行機か推進状態を創設してはいけません。
The remaining procedures are broken down into three sub-sections. The term "resynchronized state", originally defined in [RFC3473], is used and modified in these sections. This term refers to LSP state that is fully recovered.
残っている手順は3つの小区分へ砕けています。 「状態を再連動した」という元々[RFC3473]で定義された用語は、これらのセクションで使用されて、変更されます。 今期は完全に回復されるLSP状態について言及します。
Signaling state may be recovered from sources other than the mechanisms defined in this document. The restarting node SHOULD consider signaling state as resynchronized for all such LSPs and follow corresponding procedures defined below. Further, recovery procedures defined below may be overridden by local policy.
本書では定義されたメカニズム以外のソースからシグナリング状態を取り戻すかもしれません。 再開ノードSHOULDはそのようなすべてのLSPsのために再連動するように状態に合図すると考えて、以下で定義された対応する手順に従います。 さらに、以下で定義されたリカバリ手順はローカルの方針でくつがえされるかもしれません。
Again, there are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
一方、セクション9.5.2で定義された手順への変化が全く再開ノードが出口ノードであるなら[RFC3473]にありません。
4.5.2.1. Path and RecoveryPath Message Procedures
4.5.2.1. 経路とRecoveryPathメッセージ手順
When a node receives a RecoveryPath message during the Recovery Period, the node first checks if it has resynchronized RSVP state associated with the message. If there is resynchronized state, and when both reliable message delivery [RFC2961] is supported and a MESSAGE_ID object is present in the RecoveryPath message, the node MUST follow Message ID acknowledgment procedures, as defined in [RFC2961], and consider the message as processed. If there is resynchronized state and there is no MESSAGE_ID object or reliable message delivery [RFC2961] is not supported, the node SHOULD send a trigger Path message, and, consider the message as processed.
ノードがRecovery Periodの間RecoveryPathメッセージを受け取るとき、ノードは、最初に、それでメッセージに関連しているresynchronized RSVP状態があるかどうかチェックします。 状態が再連動して、両方であるときに、信頼できるメッセージ配送[RFC2961]が支持されて、MESSAGE_ID物がRecoveryPathメッセージに存在しているなら、ノードは、処理されるように[RFC2961]で定義されるようにMessage ID承認手順に従って、メッセージを考えなければなりません。 状態が再連動して、MESSAGE_ID物が全くないか、または信頼できるメッセージ配送[RFC2961]が支持されないなら、ノードSHOULDは引き金のPathメッセージを送ります、そして、処理されるようにメッセージを考えてください。
If a non-resynchronized state is found or the node is the ingress, the node saves the information contained in the RecoveryPath message and continues with processing as defined in Section 4.5.2.2.
非再連動している状態が見つけられるか、ノードがイングレスであるなら、ノードは、RecoveryPathメッセージに含まれた情報を保存して、セクション4.5.2で.2に定義されるように処理を続行します。
If no associated RSVP state is found and the node is not the ingress node, the node saves the information contained in the RecoveryPath message for later use.
どんな関連RSVP状態も見つけられないで、またノードがイングレスノードでないなら、ノードは後の使用へのRecoveryPathメッセージに含まれた情報を保存します。
Note the following modifies Section 9.5.2 of [RFC3473]:
以下が.2セクション9.5[RFC3473]を変更することに注意してください:
When a node receives a Path message during the Recovery Period, the node first locates any RSVP state associated with the message. If resynchronized RSVP state is found, then the node handles this message according to previously defined procedures.
ノードがRecovery Periodの間Pathメッセージを受け取るとき、ノードは最初に、メッセージに関連しているどんなRSVP状態も場所を見つけます。 resynchronized RSVP状態が見つけられるなら、以前に定義された手順によると、ノードはこのメッセージを扱います。
Satyanarayana & Rahman Standards Track [Page 11] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[11ページ]RFC5063GMPLS RSVP
If a non-resynchronized state is found, the node saves the information contained in the Path message, including the Recovery_Label object, and continues with processing as defined in Section 4.5.2.2.
非再連動している状態が見つけられるなら、ノードは、Recovery_Label物を含むPathメッセージに含まれた情報を保存して、セクション4.5.2で.2に定義されるように処理を続行します。
Per [RFC3473], if matching RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
[RFC3473]に従って、合っているRSVP状態が見つけられないで、またメッセージがRecovery_Label物を運ばないなら、ノードは、新しいLSPのためにセットアップとしてこれを扱って、以前に定義された手順によると、それを扱います。
If a matching RSVP state is not found and the message carries a Recovery_Label object, the node saves the information contained in the Path message, including the Recovery_Label object for later use.
合っているRSVP状態が見つけられないで、メッセージがRecovery_Label物を運ぶなら、ノードはPathメッセージに含まれた情報を保存します、後の使用のためのRecovery_Label物を含んでいて。
4.5.2.2. Re-Synchronization Procedures
4.5.2.2. 再同期手順
After receipt of the RecoveryPath message and, for non-ingress LSPs, the corresponding Path message with a Recovery Label object, the restarting node SHOULD locate and associate corresponding forwarding state using the received information. The restarting node associates the corresponding active forwarding plane state from the following signaled information:
RecoveryPathメッセージと非イングレスLSPsへのRecovery Label物がある対応するPathメッセージの領収書の後に、再開ノードSHOULDは、受信された情報を使用することで対応する推進状態を場所を見つけて、関連づけます。 再開ノードは以下の合図された情報から対応する活動的な推進飛行機状態を関連づけます:
The upstream data interface is recovered from the RSVP HOP object
in the received Path message.
受信されたPathメッセージで上流のデータインタフェースからRSVP HOP物を取り戻します。
The label on the upstream data interface is recovered from the
Recovery Label object in the received Path message. If the LSP is
bidirectional, the label for the upstream direction is recovered
from the Upstream Label object in the received Path message.
受信されたPathメッセージで上流のデータインタフェースのラベルからRecovery Label物を取り戻します。 LSPが双方向であるなら、受信されたPathメッセージで上流の指示のためのラベルからUpstream Label物を取り戻します。
The downstream data interface is recovered from the RSVP HOP
object in the received RecoveryPath message.
受信されたRecoveryPathメッセージで川下のデータインタフェースからRSVP HOP物を取り戻します。
The label on the downstream data interface is recovered from the
Recovery Label object in the received RecoveryPath message. If
the LSP is bidirectional, the label for the upstream direction is
recovered from the Upstream Label object in the RecoveryPath
message.
受信されたRecoveryPathメッセージで川下のデータインタフェースのラベルからRecovery Label物を取り戻します。 LSPが双方向であるなら、RecoveryPathメッセージで上流の指示のためのラベルからUpstream Label物を取り戻します。
If complete forwarding state is located, the restarted node MUST treat the LSP as resynchronized and MUST send a trigger Path message downstream. The Explicit Route object in the Path message SHOULD match the Explicit Route object received in the RecoveryPath message. In addition, the restarted node SHOULD recover state from the other objects received in the RecoveryPath message. Optimally, the resulting Path message should not cause any redundant or unnecessary reprocessing of state along the remaining downstream nodes. Ideally,
完全な推進状態が見つけられているなら、再開しているノードは、再連動するようにLSPを扱わなければならなくて、引き金のPathメッセージを川下に送らなければなりません。 Explicit RouteはExplicit Route目的がRecoveryPathメッセージで受けたPathメッセージSHOULDマッチで反対します。 さらに、再開しているノードSHOULDはRecoveryPathメッセージに受け取られた他の物から状態を取り戻します。 最適に、結果として起こるPathメッセージは残っている川下のノードに沿って状態のどんな余分であるか不要な再処理も引き起こすべきではありません。 理想的に
Satyanarayana & Rahman Standards Track [Page 12] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[12ページ]RFC5063GMPLS RSVP
except for MESSAGE_ID processing and recovery processing, the transmitted Path message will be treated as a refresh by the downstream RSVP neighbor (and hence, should not trigger any generation of Path messages with changed state further downstream).
MESSAGE_ID処理とリカバリ処理を除いて、aが川下のRSVP隣人でリフレッシュするとき(したがって、変えられた状態と共に川下でどんな世代のPathメッセージもさらに引き金となるべきではありません)、伝えられたPathメッセージは扱われるでしょう。
If no forwarding state is located, the node treats the received Path message as a setup request for a new LSP. The outgoing interface and label(s) indicated in the RecoveryPath message SHOULD be reused when possible. All other information contained in the RecoveryPath message MAY also be used. That is, forwarding state MUST NOT be created except after receipt of a Path message from upstream or, at an ingress node, the receipt of a command from the management plane. Further, the forwarding state created is subject to local policy and the information received from downstream in the RecoveryPath message is treated only as advisory.
推進状態が全く見つけられていないなら、ノードは新しいLSPを求めるセットアップ要求として受信されたPathメッセージを扱います。 外向的なインタフェースとラベルは、RecoveryPathメッセージSHOULDで可能であるときには再利用されるように示しました。 また、RecoveryPathメッセージに含まれた他のすべての情報が使用されるかもしれません。 Pathメッセージの領収書の後以外に、上流か管理飛行機からのイングレスノードのコマンドの領収書からすなわち、推進状態を創設してはいけません。 さらに、州が作成した推進は状況報告としてローカルの方針と受け取って、RecoveryPathメッセージの川下が扱われるという情報だけを受けることがあります。
4.5.2.3. Procedures on Expiration of Recovery Period
4.5.2.3. 回復の期間の満了の手順
There are several cleanup steps to follow at the end of the Recovery Period. At the end of the Recovery Period, any state that was installed as the result of a received RecoveryPath message that is not resynchronized SHOULD be discarded.
Recovery Periodの端で従ういくつかのクリーンアップ方法があります。 Recovery Periodの端、resynchronized SHOULDでない受信されたRecoveryPathメッセージの結果としてインストールされたあらゆる状態で、捨てられてください。
Any Path messages that were received containing a Recovery_Label that has not been resynchronized, MUST be treated as being received during the Recovery Period and processed as per [RFC3473].
それがどんなPathメッセージであったも再連動していないRecovery_Labelを含んでいて、受け取られて、Recovery Periodの間、受け取られているとして扱われて、[RFC3473]に従って処理しなければなりません。
Per [RFC3473], any other state that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.
[RFC3473]、Recovery Period SHOULDの間に再連動しないいかなる他の状態に従って、Periodの端で取り除いてください。
4.6. Compatibility
4.6. 互換性
This document introduces a new RSVP signaling message called the RecoveryPath message to be generated by the downstream RSVP neighbor of a restarting node. To advertise the capability of sending and receiving RecoveryPath messages, this document introduces the Capability object to be included in Hello messages by a restarting node and its downstream RSVP neighbors.
このドキュメントは再開ノードの川下のRSVP隣人を発生させるべきRecoveryPathメッセージと呼ばれる新しいRSVPシグナリングメッセージを紹介します。 送受信RecoveryPathメッセージの能力の広告を出すなら、Helloメッセージで再開しているノードとその川下のRSVP隣人によって入れられるように、このドキュメントはCapability物を紹介します。
If a restarting node does not support the Capability object, it will discard the object, as the Class-Number is of the form 10bbbbbb, and revert to recovery processing as defined in [RFC3473]. The restarting node will not include the Capability object in its Hello messages. Hence, all downstream RSVP neighbors that detect that the restarting node is not capable of supporting the extensions defined in this document will not send the RecoveryPath messages to the restarting node and will revert to recovery processing as defined in [RFC3473].
再開ノードがCapability物を支えないと、それは、[RFC3473]で定義されるようにClass-数がフォーム10bbbbbbのものであって物を捨てて、リカバリ処理に戻るでしょう。 再開ノードはHelloメッセージにCapability物を含まないでしょう。 したがって、それが検出する再開ノードは本書では定義された拡大を支持しながらできないすべての川下のRSVP隣人が、RecoveryPathメッセージを再開ノードに送らないで、[RFC3473]で定義されるようにリカバリ処理に先祖帰りをするでしょう。
Satyanarayana & Rahman Standards Track [Page 13] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[13ページ]RFC5063GMPLS RSVP
If a downstream RSVP neighbor does not support the Capability object, it will discard the object received in Hello messages and revert to recovery processing as defined in [RFC3473]. The downstream RSVP neighbor will not include the Capability object in its Hello messages. Hence, the restarting node will detect that the downstream RSVP neighbor is not capable of supporting the extensions defined in this document and will revert to recovery processing as defined in [RFC3473].
川下のRSVP隣人がCapability物を支えないと、それは、[RFC3473]で定義されるようにHelloメッセージに受け取られた物を捨てて、リカバリ処理に戻るでしょう。 川下のRSVP隣人はHelloメッセージでCapability物を入れないでしょう。 したがって、川下のRSVP隣人は本書では定義された拡大を支持しながらできない再開ノードが検出するでしょう、そして、[RFC3473]で定義されるようにリカバリ処理に戻るでしょう。
5. RecoveryPath Summary Refresh
5. RecoveryPath概要はリフレッシュします。
This section describes a mechanism to control which LSP state is communicated in RecoveryPath messages. This mechanism enhances the Summary Refresh mechanism defined in [RFC2961], and uses the RecoveryPath Srefresh Capable (S) bit in the Capability object, as defined in Section 4.2, carried in the Hello message defined in [RFC3209] and [RFC3473]. The described mechanism is referred to as RecoveryPath Summary Refresh.
このセクションは、どのLSP状態がRecoveryPathメッセージで伝えられるかを制御するためにメカニズムについて説明します。 このメカニズムは、[RFC2961]で定義されたSummary Refreshメカニズムを高めて、Capability物でRecoveryPath Srefresh Capable(S)ビットを使用します、[RFC3209]と[RFC3473]で定義されたHelloメッセージで運ばれたセクション4.2で定義されるように。 説明されたメカニズムはRecoveryPath Summary Refreshと呼ばれます。
Selective transmission of RecoveryPath messages is controlled much the same way transmission of Path or Resv messages is controlled with standard Summary Refresh, see [RFC2961]. In standard Summary Refresh, an Srefresh message is sent by a node to identify to its neighbor about Path and Resv state that is locally installed and available. The receiver of the Srefresh message can then attempt to locate matching Path and Resv state. If no matching state is found, the receiver can request that the missing state be sent to it by sending an Srefresh NACK to the sender of the Srefresh message. When the Srefresh NACK is received, the corresponding Path or Resv message is sent. MESSAGE_ID information is used to identify Path and Resv state in this process.
RecoveryPathメッセージの選択式変速機はPathかResvメッセージの伝達が標準のSummary Refreshと共に制御される制御似たり寄ったりの方法です、と[RFC2961]は見ます。 標準のSummary Refreshでは、SrefreshメッセージはPathの周りで隣人に特定するノードと局所的にインストールされて、利用可能なResv州によって送られます。 そして、Srefreshメッセージの受信機は、合っているPathとResv状態の場所を見つけるのを試みることができます。 合っている状態が全く見つけられないなら、受信機は、なくなった状態がSrefreshメッセージの送付者にSrefreshナックを送ることによってそれに送られるよう要求できます。 Srefreshナックが受け取られているとき、対応するPathかResvメッセージを送ります。 MESSAGE_ID情報は、この過程でPathとResv状態を特定するのに使用されます。
The mechanism described in this section extends the Summary Refresh process to the Path state that can be represented in RecoveryPath messages. In this case, the Srefresh messages represent previously received Path messages, rather than previously transmitted Path messages. This is the primary difference between standard Summary Refresh and RecoveryPath Summary Refresh described in this section.
このセクションで説明されたメカニズムはRecoveryPathメッセージに表すことができるPath状態にSummary Refreshの過程を広げています。 この場合、メッセージが以前に表すSrefreshは以前にPathメッセージを送るよりむしろPathメッセージを受け取りました。 これはこのセクションで説明された標準のSummary RefreshとRecoveryPath Summary Refreshの第一の違いです。
When a node restarts, and is capable of supporting the mechanisms described in this section, it includes the Capability object with the RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh Capable (S) bit set in Hello messages it sends to its RSVP neighbors.
ノードが再開して、このセクションで説明されたメカニズムをサポートできるとき、それはRecoveryPath Desired(R)ビットがセットして、RecoveryPath Srefresh Capable(S)ビットがそれがRSVP隣人に送るHelloメッセージに設定されているCapability物を含んでいます。
When a neighbor of the restarting node detects a restart (see [RFC3209]), it detects that the restarted node is capable of receiving RecoveryPath messages, as defined in Section 4.4, and that the restarted node is requesting RecoveryPath Srefresh messages by
再開ノードの隣人が再開を検出するとき([RFC3209]を見てください)、それは再開しているノードがセクション4.4で定義されるようにRecoveryPathメッセージを受け取りながらできて、再開しているノードがRecoveryPath Srefreshメッセージを要求しているそれを検出します。
Satyanarayana & Rahman Standards Track [Page 14] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[14ページ]RFC5063GMPLS RSVP
the RecoveryPath Srefresh Capable (S) bit set in the Capability object. When such an indication is found, the neighbor generates one or more Srefresh messages. Each message indicates the Path state that can be represented in a RecoveryPath message. Within such Srefresh messages, the Path state that can be represented in RecoveryPath messages is represented using MESSAGE_ID information, and this information is communicated within MESSAGE_ID LIST objects. To indicate that the MESSAGE_ID LIST object is for recovery purposes, a new flag is set in the MESSAGE_ID LIST object. This flag is called the RecoveryPath Flag and is defined below.
RecoveryPath Srefresh Capable(S)ビットはCapability物にセットしました。 そのような指示が見つけられるとき、隣人は1つ以上のSrefreshメッセージを発生させます。 各メッセージはRecoveryPathメッセージに表すことができるPath状態を示します。 そのようなSrefreshメッセージの中では、RecoveryPathメッセージに表すことができるPath状態はMESSAGE_ID情報を使用することで表されて、この情報はMESSAGE_ID LIST物の中に伝えられます。 MESSAGE_ID LIST物が回復目的のためのものであることを示すために、新しい旗はMESSAGE_ID LIST物に設定されます。 この旗は、RecoveryPath Flagと呼ばれて、以下で定義されます。
The restarted node can then use the Srefresh message and the MESSAGE_ID LIST object to try to identify matching transmitted Path state. The node identifies local state by matching Epoch and Message ID tuples against Path messages transmitted downstream prior to the restart.
そして、再開しているノードは、合っている伝えられたPath状態を特定しようとするためにSrefreshメッセージとMESSAGE_ID LIST物を使用できます。 ノードは合っているEpochとMessage ID tuplesのそばで再開の前に川下に送られたPathメッセージに対して地方の状態を特定します。
If matching state is located, then the restarted node operates as if a RecoveryPath message has been received, per Section 4.5.2. If no matching state can be located, the restarted node generates a Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is also marked with the new RecoveryPath Flag to indicate that the NACK is related to RecoveryPath messages.
合っている状態が見つけられているなら、再開しているノードはまるでRecoveryPathメッセージを受け取ったかのように作動します、セクション4.5.2単位で。 [RFC2961]のセクション5.4は、合っている状態の全く見つけることができないなら、再開しているノードがSrefreshナックを発生させるのを見ます。 また、Srefreshナックは、ナックがRecoveryPathメッセージに関連するのを示すために新しいRecoveryPath Flagと共にマークされます。
Upon receiving a Srefresh NACK, the downstream node generates a RecoveryPath message for the Path state indicated by each entry in the MESSAGE_ID LIST. The procedures defined in Section 4 above are then followed by the restarted node and the downstream RSVP neighbor.
Srefreshナックを受けると、川下のノードはMESSAGE_ID LISTの各エントリーで示されたPath状態へのRecoveryPathメッセージを発生させます。次に、上のセクション4で定義された手順は再開しているノードと川下のRSVP隣人によって従われています。
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
5.1. メッセージ_ID ACK/ナックとメッセージ_IDリスト物
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, defined in [RFC2961], are updated by this document. A new bit within the existing Flags field of each object is defined. This bit indicates that the object carries MESSAGE_ID information related to Path state that can be recovered using RecoveryPath messages. The same flag value is used in all the objects for consistency.
このドキュメントは[RFC2961]で定義されたMESSAGE_ID ACK/ナック物とMESSAGE_ID LIST物をアップデートします。 それぞれの物の既存のFlags分野の中の新しいビットは定義されます。 このビットは、物がRecoveryPathメッセージを使用することで回復できるPath状態に関連するMESSAGE_ID情報を運ぶのを示します。 同じ旗の値は一貫性にすべての物で使用されます。
Satyanarayana & Rahman Standards Track [Page 15] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[15ページ]RFC5063GMPLS RSVP
MESSAGE_ID_ACK object MESSAGE_ID_NACK object
MESSAGE_ID_ACK物のMESSAGE_ID_ナック物
See Section 4.3 of [RFC2961] for definition of other fields.
他の分野の定義に関して[RFC2961]のセクション4.3を見てください。
MESSAGE_ID LIST object
MESSAGE_ID LIST物
See Section 5.1 of [RFC2961] for definition of other fields.
他の分野の定義に関して[RFC2961]のセクション5.1を見てください。
Flags: 8 bits
旗: 8ビット
0x02: RecoveryPath Flag
0×02: RecoveryPath旗
Indicates that the associated object carries MESSAGE_ID
information related to one or more Path messages that can be
recovered using a RecoveryPath message.
関連物がRecoveryPathメッセージを使用することで回復できる1つ以上のPathメッセージに関連するMESSAGE_ID情報を運ぶのを示します。
5.2. RecoveryPath Srefresh Capable Bit
5.2. RecoveryPath Srefreshできるビット
The Capability object and the RecoveryPath Srefresh Capable (S) bit are defined in Section 4.2.
Capability物とRecoveryPath Srefresh Capable(S)ビットはセクション4.2で定義されます。
5.2.1. Procedures
5.2.1. 手順
To support the selective receipt of RecoveryPath messages as defined in this section, a restarting node MUST support the receipt and processing of RecoveryPath messages as defined in Section 4.5.2, and MUST indicate this capability by including the Capability object with the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in its Hello messages.
再開ノードは、このセクションで定義されるようにRecoveryPathメッセージの選択している領収書を支えるために、セクション4.5.2で定義されるようにRecoveryPathメッセージの領収書と処理を支えなければならなくて、RecoveryPath Desired(R)ビットがあるCapability物を含んでいるのによるこの能力がHelloメッセージのセクション4.4.2で定義されるようにセットしたのを示さなければなりません。
To indicate to an RSVP neighbor that selective transmission of RecoveryPath messages is desired, a node MUST set (1) the S-bit in the Capability object in all Hello messages it sends. When the restarting node does not desire the receipt of RecoveryPath messages (see Section 4.4.2) or the selective transmission mechanism defined in this section, it MUST clear (0) the S-bit in the Capability object if included in Hello messages.
RecoveryPathメッセージの選択式変速機が望まれているのをRSVP隣人に示すために、ノードはそれが送るすべてのHelloメッセージに(1) SでCapabilityで噛み付いている物を設定しなければなりません。 再開ノードがRecoveryPathメッセージ(セクション4.4.2を見る)の領収書かこのセクションで定義された選択している効果波及経路を望んでいないとき、Helloメッセージに含まれているなら、それは(0) SでCapabilityで噛み付いている物をきれいにしなければなりません。
The downstream RSVP neighbor checks the R-bit and the S-bit upon detecting a restart of a node that supports state recovery with RecoveryPath messages. Detection of neighbor restarts with state recovery using RecoveryPath messages is defined in Section 4. If both the R-bit and the S-bit are set, then the procedures defined below in Section 5.3.1 MUST be followed. If the S-bit is cleared, the downstream RSVP neighbor MUST revert to normal procedures defined in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the
RecoveryPathメッセージで州の回復を支えるノードの再開を検出するとき、川下のRSVP隣人はR-ビットとS-ビットをチェックします。 州の回復がRecoveryPathメッセージを使用している隣人再開の検出はセクション4で定義されます。 R-ビットとS-ビットの両方が設定されるなら、以下でセクション5.3.1で定義された手順に従わなければなりません。 S-ビットがきれいにされるなら、川下のRSVP隣人はセクション4.5.1で定義された正常な手順に先祖帰りをしなければなりません。 R-ビットがきれいにされますが、S-ビットが設定されるなら
Satyanarayana & Rahman Standards Track [Page 16] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[16ページ]RFC5063GMPLS RSVP
downstream RSVP neighbor MUST treat it as if the Capability object was received with the S-bit cleared. See Section 4.4 for handling of Hello messages without the Capability object.
川下のRSVP隣人はまるでS-ビットがきれいにされている状態でCapability物を受け取るかのようにそれを扱わなければなりません。 Helloメッセージの取り扱いに関してCapability物なしでセクション4.4を見てください。
5.2.2. Compatibility
5.2.2. 互換性
There are no compatibility issues introduced in the procedures defined in Section 5.2.1.
セクション5.2.1で定義された手順で紹介された互換性の問題が全くありません。
The restarting node will detect that its neighbor does not support selective transmission of RecoveryPath messages when a RecoveryPath message is received prior to the receipt of a Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set (1). When this occurs, any received RecoveryPath messages MUST be processed as defined in Section 4.
RecoveryPath Flagセット(1)でRecoveryPathメッセージであるときに隣人がRecoveryPathメッセージのサポート選択していない伝達をするノードが検出する再開をMESSAGE_ID LIST物を含むSrefreshメッセージの領収書の前に受け取ります。 これが起こるとき、どんな受信されたRecoveryPathメッセージとしても、セクション4で定義されていた状態で処理しなければなりません。
5.3. RecoveryPath Summary Refresh Procedures
5.3. RecoveryPath概要は手順をリフレッシュします。
Related processing occurs in the following logical order:
関連処理は以下の論理的順序に起こります:
o Generation of RecoveryPath-related Srefresh messages
o RecoveryPath関連のSrefreshメッセージの世代
o RecoveryPath-related Srefresh message receive processing and NACK
generation
o RecoveryPath関連のSrefreshメッセージは処理とナック世代を受けます。
o Message ID NACK receive processing and generation of RecoveryPath
messages
o IDナックが処理と世代に関するRecoveryPathメッセージを受け取るというメッセージ
o Receive processing of RecoveryPath messages
o RecoveryPathメッセージの処理を受けてください。
Actual processing MAY result in the above occurring in an interlaced fashion when multiple LSPs are being recovered. Both the restarted node and the downstream RSVP neighbor MUST be able to process in this fashion.
複数のLSPsが回収されているとき、実際の処理は交錯しているファッションで上の発生をもたらすかもしれません。 再開しているノードと川下のRSVP隣人の両方がこんなやり方で処理できなければなりません。
5.3.1. Generation of RecoveryPath-Related Srefresh Messages
5.3.1. RecoveryPath関連のSrefreshメッセージの世代
A neighbor of a restarting node generates one or more RecoveryPath- related Srefresh messages when the S-bit is set in the restarted node's Hello messages as described in Section 5.2.1. The procedures for generating an Srefresh message are defined in [RFC2961]. Only modifications to these procedures are described in this section. Also, Srefresh message transmit and receive processing may occur simultaneously during the Recovery Period and are not impacted by the procedures defined in this section.
S-ビットがセクション5.2.1で説明されるように再開しているノードのHelloメッセージに設定されるとき、再開ノードの隣人は1つ以上のRecoveryPathの関連するSrefreshメッセージを発生させます。 Srefreshメッセージを発生させるための手順は[RFC2961]で定義されます。 変更だけがこのセクションでこれらの手順に説明されます。 また、メッセージが処理するのを送受信するSrefreshは同時に、Recovery Periodの間、起こるかもしれなくて、このセクションで定義された手順で影響を与えられません。
To generate RecoveryPath-related Srefresh messages, a node must identify which Path state can be represented in RecoveryPath messages
RecoveryPath関連のSrefreshメッセージを発生させるように、ノードは、RecoveryPathメッセージにどのPath状態を表すことができるかを特定しなければなりません。
Satyanarayana & Rahman Standards Track [Page 17] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[17ページ]RFC5063GMPLS RSVP
and which Srefresh message or messages can be used to carry the related information. As previously mentioned, the Path state that can be represented in RecoveryPath messages is indicated in Srefresh messages using the MESSAGE_ID information from the most recently received Path message associated with the state.
そして、関連情報を運ぶのにどのSrefreshメッセージかメッセージを使用できますか? 以前に言及されるように、RecoveryPathメッセージに表すことができるPath状態はSrefreshメッセージで状態に関連している最も最近受信されたPathメッセージからのMESSAGE_ID情報を使用することで示されます。
After processing the S-bit as described in Section 5.2.1, the node identifies all state associated with Path messages received from the restarted neighbor. Only a Path state that has not been updated since the restart may be represented in the Srefresh messages. Received Path state containing a MESSAGE_ID object whose Epoch value matches the Epoch received in the most recent Hello message is considered as updated after the upstream neighbor has restarted. Such Path state MUST NOT be represented in the Srefresh messages. Each Srefresh message contains one or more MESSAGE_ID LIST objects. Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1).
セクション5.2.1で説明されるようにS-ビットを処理した後に、ノードは再開している隣人から受け取るPathメッセージに関連しているすべての状態を特定します。 Srefreshメッセージに再開以来アップデートされていないPath状態だけを表してもよいです。 容認されたPathは、上流の隣人が再開した後にアップデートするようにEpochが最新のHelloメッセージでEpoch値のマッチを受けたMESSAGE_ID物を含むのが考えられると述べます。 SrefreshメッセージにそのようなPath状態を表してはいけません。 それぞれのSrefreshメッセージは1個以上のMESSAGE_ID LIST物を含んでいます。 そのようなそれぞれのMESSAGE_ID LIST物で、RecoveryPath Flagは(1)を設定しなければなりません。
Multiple MESSAGE_ID LIST objects MAY be included in order to accommodate multiple Epoch values. The MESSAGE_ID LIST objects represent the identified, non-updated, Path state. A Message_Identifier field created for each identified, non-updated Path state MUST be included in an appropriate MESSAGE_ID LIST object. The Message_Identifier field is created based on the MESSAGE_ID object from the most recently received Path message associated with identified Path state. If any identified Path state does not have an associated MESSAGE_ID object, this state MUST be processed as defined above in Section 4.5.1.
複数のMESSAGE_ID LIST物が、複数のEpoch値を収容するために含まれるかもしれません。 MESSAGE_ID LIST物は特定されて、非アップデートされたPath状態を表します。 適切なMESSAGE_ID LIST物にそれぞれの特定されて、非アップデートされたPath状態に作成されたMessage_Identifier分野を含まなければなりません。 Message_Identifier分野は特定されたPath状態に関連している最も最近受信されたPathメッセージからのMESSAGE_ID物に基づいて作成されます。 どんな特定されたPath州にも関連MESSAGE_ID物がないなら、この状態として上でセクション4.5.1で定義されていた状態で処理しなければなりません。
The source IP address for the Srefresh message SHOULD be the source IP address in the IP header of the corresponding Resv messages previously sent to the restarted node. The Srefresh message SHOULD be destined to the IP address in the HOP object in the corresponding Path messages. This may result in multiple Srefresh messages being generated. Per [RFC2961], implementations may choose to limit each Srefresh message to the MTU size of the outgoing link, and to not bundle Srefresh messages. RecoveryPath-related Srefresh messages SHOULD be sent using reliable delivery, as defined in [RFC2961].
ソースIPはソースIPが以前に再開しているノードに送られた対応するResvメッセージのIPヘッダーのアドレスであったならSrefreshメッセージのためにSHOULDを記述します。 SrefreshはSHOULDを通信させます。対応するPathメッセージのHOP物のIPアドレスに運命づけられてください。 これは発生する複数のSrefreshメッセージをもたらすかもしれません。 [RFC2961]に従って、実現は、それぞれのSrefreshメッセージを出発しているリンクのMTUサイズに制限して、Srefreshメッセージを束ねないのを選ぶかもしれません。 RecoveryPath関連のSrefreshは送られた使用が信頼できる配信であったなら[RFC2961]で定義されるようにSHOULDを通信させます。
During the Recovery Period, unacknowledged RecoveryPath-related Srefresh messages SHOULD be periodically transmitted. The retransmission algorithm used can be the same algorithm used for retransmitting RecoveryPath messages during the Recovery Period (see Section 4.5.1). Note that prior to each such periodic retransmission, the Srefresh message SHOULD be updated to exclude the Message ID's of Path state that has been updated by the receipt of a Path message.
Recovery Periodの間、伝えられて、定期的に不承認のRecoveryPath関連のSrefreshメッセージSHOULDはそうです。 使用される再送信アルゴリズムはRecovery Periodの間、RecoveryPathメッセージを再送するのに使用される同じアルゴリズムであるかもしれません(セクション4.5.1を見てください)。 Message IDのPathメッセージの領収書でアップデートされたPath状態のものを除くためにそのような周期的な「再-トランスミッション」、それぞれ前にSrefreshメッセージSHOULDをアップデートすることに注意してください。
Satyanarayana & Rahman Standards Track [Page 18] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[18ページ]RFC5063GMPLS RSVP
To allow sufficient processing time for the restarted node, the downstream RSVP neighbor MAY choose to generate multiple RecoveryPath-related Srefresh messages containing partial but mutually exclusive sets of Message Identifiers spread across 1/4 of the Recovery Time advertised by the restarted node.
再開しているノードのための十分な処理時間を許容するために、川下のRSVP隣人は、再開しているノードによって広告に掲載された1/4Recovery Timeの向こう側に広げられたMessage Identifiersの部分的な、しかし、互いに唯一のセットを含む複数のRecoveryPath関連のSrefreshメッセージを発生させるのを選ぶかもしれません。
5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK
Generation
5.3.2. RecoveryPath関連のSrefreshは処理とナック世代を受けます。
Upon receiving an Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set), the restarted node attempts to locate matching previously transmitted Path state. The Epoch in the MESSAGE_ID LIST object, along with each Message Identifier in the object, is used to match against the MESSAGE_ID object in Path messages previously transmitted to the downstream RSVP neighbor. For each Message Identifier in the MESSAGE_ID LIST:
受信のRecoveryPath FlagセットがあるMESSAGE_ID LIST物を含むSrefreshメッセージ)、再開しているノードは、以前に伝えられた合っているPath状態の場所を見つけるのを試みます。 MESSAGE_ID LIST物のEpochは、以前に川下のRSVP隣人に送られたPathメッセージでMESSAGE_ID物に対して合うのに物の各Message Identifierと共に使用されます。 MESSAGE_ID LISTの各Message Identifierのために:
If matching transmitted Path state is found, the restarting node
treats the corresponding LSP state as having received and
processed a RecoveryPath message and perform any further
processing necessary as defined in Section 4.5.2. Specifically,
it MUST generate a trigger Path message for the LSP as defined in
Section 4.5.2.2. The restarted node MAY spread the transmission
of such trigger Path messages across 1/2 of the remaining Recovery
Period to allow the downstream RSVP neighbor sufficient processing
time.
合っている伝えられたPath状態が見つけられるなら、再開ノードはRecoveryPathメッセージを受け取って、処理したとして対応するLSP状態を扱います、そして、セクション4.5.2における定義されるとして必要なさらなるあらゆる処理を実行してください。 明確に、それはセクション4.5.2で.2に定義されるようにLSPへの引き金のPathメッセージを発生させなければなりません。 再開しているノードは川下のRSVP隣人十分な処理時間を許容する1/2残っているRecovery Periodの向こう側のそのような引き金のPathメッセージの伝達を広げるかもしれません。
If matching transmitted Path state is not found, the restarting
node MUST generate a MESSAGE_ID NACK as defined in [RFC2961].
Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set
(1).
合っている伝えられたPath状態が見つけられないなら、再開ノードは[RFC2961]で定義されるようにMESSAGE_IDナックを発生させなければなりません。 それぞれの発生しているMESSAGE_IDナックはRecoveryPath Flagに(1)を設定させなければなりません。
It is recommended that the restarted node combine multiple such MESSAGE_ID NACKs into a single ACK message, per [RFC2961].
再開しているノードがそのような倍数MESSAGE_ID NACKsをただ一つのACKメッセージに結合するのは、[RFC2961]単位でお勧めです。
5.3.3. RecoveryPath-Related MESSAGE_ID NACK Receive Processing
5.3.3. RecoveryPath関連のメッセージ_IDナックは処理を受けます。
This section defines the procedures associated with the processing of received MESSAGE_ID NACKs that have the RecoveryPath Flag set (1). Procedures for processing of MESSAGE_ID NACKs without the RecoveryPath Flag present are defined in [RFC2961] and not modified in this document. Processing of MESSAGE_ID NACKs with the RecoveryPath Flag set (1) also follows procedures defined in [RFC2961] unless explicitly modified in this section.
このセクションはRecoveryPath Flagに(1)を設定させる容認されたMESSAGE_ID NACKsの処理に関連している手順を定義します。 存在しているRecoveryPath FlagのないMESSAGE_ID NACKsの処理のための手順は、[RFC2961]で定義されて、本書では変更されません。 また、RecoveryPath Flagセット(1)があるMESSAGE_ID NACKsの処理はこのセクションで明らかに変更されない場合[RFC2961]で定義された手順に従います。
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the downstream RSVP neighbor must locate the matching received Path message. If a matching Path message is found, the downstream RSVP
RecoveryPath Flagセット(1)をもっているそれぞれのMESSAGE_IDナックに関しては、川下のRSVP隣人は合っている受信されたPathメッセージの場所を見つけなければなりません。 合っているPathであるなら、メッセージは見つけられて、川下はRSVPです。
Satyanarayana & Rahman Standards Track [Page 19] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[19ページ]RFC5063GMPLS RSVP
neighbor MUST generate a RecoveryPath message as defined in Section 4.5.1. If a matching Path message is not found, the MESSAGE_ID NACK is ignored. An example where this may occur is when the restarted node has already generated an updated Path message after its restart.
隣人はセクション4.5.1で定義されるようにRecoveryPathメッセージを発生させなければなりません。 合っているPathメッセージが見つけられないなら、MESSAGE_IDナックは無視されます。 これが起こるかもしれない例は再開しているノードが再開の後にアップデートされたPathメッセージを既に発生させた時です。
6. Security Considerations
6. セキュリティ問題
This document introduces a new RSVP message that is restricted to one RSVP hop. This document introduces no new security considerations beyond those already addressed for existing RSVP hop-by-hop messages.
このドキュメントは1つのRSVPホップに制限される新しいRSVPメッセージを紹介します。 このドキュメントはホップごとの既存のRSVPメッセージのために既に記述されたものを超えてどんな新しいセキュリティ問題も紹介しません。
This document introduces a new RSVP object to be included in RSVP Hello messages. This document introduces no new security considerations beyond those already addressed for existing objects in RSVP Hello messages.
このドキュメントは、RSVP Helloメッセージに含まれるように新しいRSVP物を紹介します。 このドキュメントはRSVP Helloメッセージの既存の物のために既に記述されたものを超えてどんな新しいセキュリティ問題も紹介しません。
This document introduces new procedures to be performed on RSVP agents that neighbor a restarting RSVP agent. In situations where the control plane in general, and the RSVP agent in particular, of a node carrying one or more LSPs is restarted due to external attacks, the procedures introduced in this document provide the ability for the restarting RSVP agent to recover the RSVP state corresponding to the LSPs with the least possible perturbation to the rest of the network. Ideally, only the neighboring RSVP agents should notice the restart and hence need to perform additional processing. This allows for a network with active LSPs to recover LSP state gracefully from an external attack without perturbing the data/forwarding plane state.
このドキュメントは、再開しているRSVPエージェントを近所付き合いさせるRSVPエージェントに実行されるために新しい手順を導入します。 1LSPsを載せるノードの一般に、制御飛行機、および特にRSVPエージェントが外部の攻撃のため再出発される状況で、本書では導入された手順は再開しているRSVPエージェントが最も可能でない摂動でLSPsに対応するRSVP状態を回復する能力をネットワークの残りに提供します。 隣接しているRSVPエージェントだけが、再開に気付いて、したがって、追加処理を実行する必要があるべきです。 これは、アクティブなLSPsとのネットワークが優雅にデータ/推進飛行機状態を混乱させないでLSP状態を外部の攻撃から取り戻すのを許容します。
[RFC2747] provides mechanisms to protect against external agents compromising the RSVP signaling state in an RSVP agent. These mechanisms, when used with the new message and procedures introduced in this document, provide the same degree of protection to the restarting RSVP agent against installing compromised signaling state from an external agent during its RSVP signaling state recovery.
[RFC2747]は、RSVPエージェントでRSVPシグナリング状態で妥協する外部物質から守るためにメカニズムを提供します。 本書では導入する新しいメッセージと手順で使用されると、これらのメカニズムは、RSVPシグナリング州の回復の間、外部のエージェントから状態に合図しながら、インストールに対するRSVPエージェントが妥協した再開に同じ度の保護を提供します。
Note that the procedures assume a full trust model between RSVP neighbors. That is, although the protocol exchanges before and after restart can be secured, and although it is possible to authenticate the identity of the neighbors, no mechanism is provided to verify that the restart information is correctly mapped from the protocol information exchanged before the restart. This is considered acceptable because a similar trust model is required for normal operation of the protocol.
手順がRSVP隣人の間の完全な信用モデルに就くことに注意してください。 すなわち、再開の前後にプロトコル交換を保証できて、隣人のアイデンティティを認証するのが可能ですが、再開情報が再開の前に交換されたプロトコル情報から正しく写像されることを確かめるためにメカニズムを全く提供しません。 同様の信用モデルがプロトコルの通常の操作に必要であるので、これは許容できると考えられます。
The procedures defined in this document introduce additional processing overhead for the RSVP agents that neighbor a restarting RSVP agent. If an RSVP agent restarts due to external attacks, such
本書では定義された手順は再開しているRSVPエージェントを近所付き合いさせるRSVPエージェントのために追加処理オーバヘッドを導入します。 RSVPエージェントが外部の攻撃のため再開するならそのようなもの
Satyanarayana & Rahman Standards Track [Page 20] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[20ページ]RFC5063GMPLS RSVP
added processing on the neighboring RSVP agents may impact their ability to perform other control plane tasks, including any processing for other LSPs that do not involve the restarting node. Such impact can be minimalized by the restarting RSVP agent using a large enough Recovery Time, so that its neighbors are provided sufficient time to handle the additional processing involved while continuing to perform their other control plane functions normally during the Recovery Period.
隣接しているRSVPエージェントにおける加えられた処理は他のコントロール飛行機タスクを実行する彼らの能力に影響を与えるかもしれません、再開ノードにかかわらない他のLSPsのためのどんな処理も含んでいて。 十分大きいRecovery Timeを使用することで再開しているRSVPエージェントによってそのような衝撃をminimalizedされることができます、通常、Recovery Periodの間、彼らの他のコントロール飛行機機能を実行し続けている間にかかわる追加処理は扱うことができるくらいの時間を隣人に提供するように。
Note that the procedures defined in this document cannot be used to create false forwarding state. The restarting node that receives a RecoveryPath message that does not match the existing forwarding state MUST NOT create or modify its forwarding state to match. A restarting node SHOULD log such an event or otherwise notify the operator since it might represent an attack.
偽の推進状態を創設するのに本書では定義された手順は用いることができないことに注意してください。 状態を進めながら存在に合っていないRecoveryPathメッセージを受け取る再開ノードは、合うように推進状態を創設してはいけませんし、また変更してはいけません。 攻撃を表すかもしれないので、再開ノードSHOULDはそのような出来事を登録するか、またはそうでなければ、オペレータに通知します。
7. Acknowledgments
7. 承認
The authors would like to thank participants of the CCAMP WG for comments and suggestions. Also thanks to Arthi Ayyangar, Adrian Farrel, Nick Neate, and Pavan Beeram for their helpful comments and feedback.
作者はコメントと提案についてCCAMP WGの関係者に感謝したがっています。 また、それらの役に立つコメントとフィードバックのためにArthi Ayyangar、エードリアン・ファレル、ニック・ニート、およびPavan Beeramをありがとうございます。
Derek Atkins provided useful discussion during SecDir review. Sam Hartman gave careful scrutiny of the security considerations and the potential impact on the RSVP-TE security trust model.
デリック・アトキンスはSecDirレビューの間、役に立つ議論を提供しました。 サム・ハートマンはRSVP-TEセキュリティ信用モデルの上のセキュリティ問題と可能性のある衝撃の慎重な精査を与えました。
Adrian Farrel edited the final revisions of this document as it progressed through IESG review.
IESGレビューで進歩をしたとき、エードリアン・ファレルはこのドキュメントの最終的な改正を編集しました。
8. IANA Considerations
8. IANA問題
[RFC2205] defines the Class-Number name space for RSVP objects. The name space is managed by IANA.
[RFC2205]はRSVP物のためにスペースというClass-数の名を定義します。 名前スペースはIANAによって管理されます。
A new RSVP object using a Class-Number of form 10bbbbbb called the Capability Object is defined in Section 4.2 in this document. The Class-Number is 134.
Capability Objectと呼ばれるフォーム10bbbbbbのClass-数を使用する新しいRSVP物はセクション4.2で本書では定義されます。 Class-数は134です。
A new RSVP message type called a RecoveryPath message is defined in Section 4.1 of this document. The RSVP message type is 30.
RecoveryPathメッセージと呼ばれる新しいRSVPメッセージタイプはこのドキュメントのセクション4.1で定義されます。 RSVPメッセージタイプは30歳です。
This document creates a new name space in the Capability object defined in Section 4.2. The new name space is a 32-bit-wide field. New registrations in this name space are to be allocated by IANA through an IETF Consensus action, per [RFC2434]. IANA also serves as the repository for this name space.
このドキュメントはセクション4.2で定義されたCapability物の新しい名前スペースを作成します。 スペースという新しい名前は幅32ビットの分野です。 この名前スペースの新しい登録証明書は[RFC2434]あたり1つのIETF Consensus動作でIANAによって割り当てられることです。 また、IANAはこの名前スペースへの倉庫として機能します。
Satyanarayana & Rahman Standards Track [Page 21] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[21ページ]RFC5063GMPLS RSVP
Section 4.2 defines the following bits in the 32-bit field of the Capability Object (134):
セクション4.2はCapability Object(134)の32ビットの分野で以下のビットを定義します:
RecoveryPath Transmit Enabled (T): 1 bit
RecoveryPath Desired (R): 1 bit
RecoveryPath Srefresh Capable (S): 1 bit
RecoveryPathが伝わる、(T)を可能にします: 1ビットのRecoveryPath Desired(R): 1ビットのRecoveryPath Srefresh Capable(S): 1ビット
9. Normative References
9. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、B.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC2961] バーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
Satyanarayana & Rahman Standards Track [Page 22] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[22ページ]RFC5063GMPLS RSVP
Editors' Addresses
エディタのアドレス
Arun Satyanarayana (editor) Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 USA Phone: +1 408 853 3206 EMail: asatyana@cisco.com
西タスマン博士カリフォルニア95134サンノゼ(米国)が電話をするアルンSatyanarayana(エディタ)シスコシステムズInc.170: +1 3206年の408 853メール: asatyana@cisco.com
Reshad Rahman (editor) Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3519 EMail: rrahman@cisco.com
オンタリオK2K3の8Eの2000Innovation Kanata博士(カナダ)が電話をするReshadラーマン(エディタ)シスコシステムズInc.: 3519年の613 254メール: rrahman@cisco.com
Authors' Addresses
作者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルフランシスWellesplein1B-2018アントウェルペンベルギー電話: +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel-lucent.be
Lou Berger LabN Consulting, L.L.C. Phone: +1 301 468 9228 EMail: lberger@labn.net
ルウバーガーLabN Consulting、L.L.C.は以下に電話をします。 +1 9228年の301 468メール: lberger@labn.net
Anca Zamfir Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3484 EMail: ancaz@cisco.com
オンタリオK2K3の8Eの2000Innovation Kanata博士(カナダ)が電話をするアンカZamfirシスコシステムズInc.: 3484年の613 254メール: ancaz@cisco.com
Junaid Israr Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3693 EMail: jisrar@cisco.com
オンタリオK2K3の8Eの2000Innovation Kanata博士(カナダ)が電話をするJunaid IsrarシスコシステムズInc.: 3693年の613 254メール: jisrar@cisco.com
Satyanarayana & Rahman Standards Track [Page 23] RFC 5063 GMPLS RSVP Graceful Restart Extensions October 2007
再開拡大2007年10月に優雅なSatyanarayanaとラーマン標準化過程[23ページ]RFC5063GMPLS RSVP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Satyanarayana & Rahman Standards Track [Page 24]
Satyanarayanaとラーマン標準化過程[24ページ]
一覧
スポンサーリンク
