From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6780.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc6780.txt (limited to 'doc/rfc/rfc6780.txt') diff --git a/doc/rfc/rfc6780.txt b/doc/rfc/rfc6780.txt new file mode 100644 index 0000000..972d623 --- /dev/null +++ b/doc/rfc/rfc6780.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Berger +Request for Comments: 6780 LabN +Updates: 2205, 3209, 3473, 4872 F. Le Faucheur +Category: Standards Track A. Narayanan +ISSN: 2070-1721 Cisco + October 2012 + + + RSVP ASSOCIATION Object Extensions + +Abstract + + The RSVP ASSOCIATION object was defined in the context of GMPLS- + controlled Label Switched Paths (LSPs). In this context, the object + is used to associate recovery LSPs with the LSP they are protecting. + This object also has broader applicability as a mechanism to + associate RSVP state. This document defines how the ASSOCIATION + object can be more generally applied. This document also defines + Extended ASSOCIATION objects that, in particular, can be used in the + context of the MPLS Transport Profile (MPLS-TP). This document + updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the + definition of the Association ID field defined in RFC 4872. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6780. + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 1] + +RFC 6780 RSVP Extensions October 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Conventions Used in This Document ..........................4 + 2. Generalized Association ID Field Definition .....................4 + 3. Non-GMPLS and Non-Recovery Usage ................................4 + 3.1. Upstream Initiated Association .............................5 + 3.1.1. Path Message Format .................................5 + 3.1.2. Path Message Processing .............................6 + 3.2. Downstream Initiated Association ...........................7 + 3.2.1. Resv Message Format .................................8 + 3.2.2. Resv Message Processing .............................8 + 3.3. Association Types ..........................................9 + 3.3.1. Resource Sharing Association Type ...................9 + 3.3.2. Unknown Association Types ..........................10 + 4. IPv4 and IPv6 Extended ASSOCIATION Objects .....................10 + 4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........11 + 4.2. Processing ................................................13 + 5. Compatibility ..................................................14 + 6. Security Considerations ........................................14 + 7. IANA Considerations ............................................15 + 7.1. IPv4 and IPv6 Extended ASSOCIATION Objects ................15 + 7.2. Resource Sharing Association Type .........................15 + 8. Acknowledgments ................................................16 + 9. References .....................................................16 + 9.1. Normative References ......................................16 + 9.2. Informative References ....................................16 + + + + + + + + + +Berger, et al. Standards Track [Page 2] + +RFC 6780 RSVP Extensions October 2012 + + +1. Introduction + + End-to-end and segment recovery are defined for GMPLS-controlled + Label Switched Paths (LSPs) in [RFC4872] and [RFC4873], respectively. + Both definitions use the ASSOCIATION object to associate recovery + LSPs with the LSP they are protecting. Additional narrative on how + such associations are to be identified is provided in [RFC6689]. + + This document expands the possible usage of the ASSOCIATION object to + non-GMPLS and non-recovery contexts. The expanded usage applies + equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP + RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. This document + also reviews how associations should be made in the case in which the + object is carried in a Path message; additionally, it defines usage + with Resv messages. This section also discusses usage of the + ASSOCIATION object outside the context of GMPLS LSPs. + + Some examples of non-LSP association being used to enable resource + sharing are: + + o Voice Call-Waiting: + + A bidirectional voice call between two endpoints, A and B, is + signaled using two separate unidirectional RSVP reservations for + the flows A->B and B->A. If endpoint A wishes to put the A-B call + on hold and join a separate A-C call, it is desirable that network + resources on common links be shared between the A-B and A-C calls. + The B->A and C->A subflows of the call can share resources using + existing RSVP sharing mechanisms, but only if they use the same + destination IP addresses and ports. Since by definition, the RSVP + reservations for the subflows A->B and A->C of the call must have + different IP addresses in the SESSION objects, this document + defines a new mechanism to associate the subflows and allow them + to share resources. + + o Voice Shared Line: + + A voice shared line is a single number that rings multiple + endpoints (which may be geographically diverse), such as phone + lines to a manager's desk and to their assistant. A Voice over IP + (VoIP) system that models these calls as multiple point-to-point + unicast pre-ring reservations would result in significantly over- + counting bandwidth on shared links, since RSVP unicast + reservations to different endpoints cannot share bandwidth. So, a + new mechanism is defined in this document to allow separate + unicast reservations to be associated and to share resources. + + + + + +Berger, et al. Standards Track [Page 3] + +RFC 6780 RSVP Extensions October 2012 + + + o Symmetric NAT: + + RSVP permits sharing of resources between multiple flows addressed + to the same destination D, even from different senders S1 and S2. + However, if D is behind a NAT operating in symmetric mode + [RFC5389], it is possible that the destination port of the flows + S1->D and S2->D may be different outside the NAT. In this case, + these flows cannot share resources using RSVP, since the SESSION + objects for these two flows outside the NAT have different + destination ports. This document defines a new mechanism to + associate these flows and allow them to share resources. + + In order to support the wider usage of the ASSOCIATION object, this + document generalizes the definition of the Association ID field + defined in RFC 4872. This generalization has no impact on existing + implementations. When using the procedures defined below, + association is identified based on exact ASSOCIATION object matching. + Some of the other matching mechanisms defined in RFC 4872, e.g., + matching based on Session IDs, are not generalized. This document + allows for, but does not specify, association type-specific + processing. + + This document also defines the Extended ASSOCIATION objects that can + be used in the context of MPLS-TP. The scope of the Extended + ASSOCIATION objects is not limited to MPLS-TP. + +1.1. 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]. + +2. Generalized Association ID Field Definition + + The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION + objects defined in [RFC4872]. The [RFC4872] definition of the field + reads: + + A value assigned by the LSP head-end. When combined with the + Association Type and Association Source, this value uniquely + identifies an association. + + This document allows for the origination of ASSOCIATION objects by + nodes other than "the LSP head-end". As such, the definition of the + Association ID field needs to be generalized to accommodate such + usage. This document defines the Association ID field of the IPv4 + and IPv6 ASSOCIATION objects as: + + + + +Berger, et al. Standards Track [Page 4] + +RFC 6780 RSVP Extensions October 2012 + + + A value assigned by the node that originated the association. + When combined with the other fields carried in the object, this + value uniquely identifies an association. + + This change in definition does not impact the procedures or + mechanisms defined in [RFC4872] or [RFC4873], nor does it impact the + existing implementations of [RFC4872] or [RFC4873]. + +3. Non-GMPLS and Non-Recovery Usage + + While the ASSOCIATION object [RFC4872] is defined in the context of + GMPLS recovery, the object can have wider application. [RFC4872] + defines the object to be used to "associate LSPs with each other", + and then defines an Association Type field to identify the type of + association being identified. It also specifies that the Association + Type field is to be considered when determining association, i.e., + there may be type-specific association rules. As defined by + [RFC4872] and reviewed in [RFC6689], this is the case for recovery + type ASSOCIATION objects. [RFC6689], notably the text related to + resource sharing types, can also be used as the foundation for a + generic method for associating LSPs when there is no type-specific + association defined. + + The remainder of this section defines the general rules to be + followed when processing ASSOCIATION objects. Object usage in both + Path and Resv messages is discussed. The usage applies equally to + GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions + [RFC2205] [RFC2207] [RFC3175] [RFC4860]. As described below, + association is always done based on matching either Path state to + Path state, or Resv state to Resv state, but not Path state to Resv + State. This section applies to the ASSOCIATION objects defined in + [RFC4872]. + +3.1. Upstream-Initiated Association + + Upstream-initiated association is represented in ASSOCIATION objects + carried in Path messages and can be used to associate RSVP Path state + across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS + tunnel is represented by an RSVP SESSION object, and multiple LSPs + may be represented within a single tunnel.) Cross-LSP association + based on Path state is defined in [RFC4872]. This section extends + that definition by specifying generic association rules and usage for + non-LSP uses. This section does not modify processing required to + support [RFC4872] and [RFC4873], which is reviewed in Section 3 of + [RFC6689]. The use of an ASSOCIATION object in a single session is + not precluded. + + + + + +Berger, et al. Standards Track [Page 5] + +RFC 6780 RSVP Extensions October 2012 + + +3.1.1. Path Message Format + + This section provides the Backus-Naur Form (BNF), see [RFC5511], for + Path messages containing ASSOCIATION objects. BNF is provided for + both MPLS and for non-LSP session usage. Unmodified RSVP message + formats and some optional objects are not listed. + + The formats for MPLS and GMPLS sessions are unmodified from [RFC4872] + and can be represented based on the BNF in [RFC3209] as: + + ::= [ ] + + + [ ] + + [ ] + [ ... ] + [ ... ] + + + The format for non-LSP sessions as based on the BNF in [RFC2205] is: + + ::= [ ] + + + [ ... ] + [ ... ] + [ ] + + In general, relative ordering of ASSOCIATION objects with respect to + each other, as well as with respect to other objects, is not + significant. Relative ordering of ASSOCIATION objects of the same + type SHOULD be preserved by transit nodes. + +3.1.2. Path Message Processing + + This section is based on, and extends, the processing rules described + in [RFC4872] and [RFC4873], which is reviewed in [RFC6689]. This + section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session + state. Note, as previously stated, this section does not modify + processing required to support [RFC4872] and [RFC4873]. + + A node sending a Path message chooses when an ASSOCIATION object is + to be included in the outgoing Path message. To indicate association + between multiple sessions, an appropriate ASSOCIATION object MUST be + included in the outgoing Path messages corresponding to each of the + associated sessions. In the absence of Association-Type-specific + rules for identifying association, the included ASSOCIATION object + + + +Berger, et al. Standards Track [Page 6] + +RFC 6780 RSVP Extensions October 2012 + + + MUST be identical. When there is an Association-Type-specific + definition of association rules, the definition SHOULD allow for + association based on identical ASSOCIATION objects. This document + does not define any Association-Type-specific rules. (See Section 3 + of [RFC6689] for a review of Association-Type-specific rules derived + from [RFC4872].) + + When creating an ASSOCIATION object, the originator MUST format the + object as defined in Section 16.1 of [RFC4872]. The originator MUST + set the Association Type field based on the type of association being + identified. The Association ID field MUST be set to a value that + uniquely identifies the specific association within the context of + the Association Source field. The Association Source field MUST be + set to a unique address assigned to the node originating the + association. + + A downstream node can identify an upstream-initiated association by + performing the following checks. When a node receives a Path + message, it MUST check each ASSOCIATION object received in the Path + message to determine if the object contains an Association Type field + value supported by the node. For each ASSOCIATION object containing + a supported association type, the node MUST then check to see if the + object matches an ASSOCIATION object received in any other Path + message. To perform this matching, a node MUST examine the Path + state of all other sessions and compare the fields contained in the + newly received ASSOCIATION object with the fields contained in the + Path state's ASSOCIATION objects. An association is deemed to exist + when the same values are carried in all fields of the ASSOCIATION + objects being compared. Type-specific processing of ASSOCIATION + objects is outside the scope of this document. + + Note that as more than one association may exist, the described + matching MUST continue after a match is identified and MUST be + performed against all local Path state. It is also possible for + there to be no match identified. + + Unless there are type-specific processing rules, downstream nodes + MUST forward all ASSOCIATION objects received in a Path message in + any corresponding outgoing Path messages without modification. This + processing MUST be followed for unknown Association Type field + values. + +3.2. Downstream-Initiated Association + + Downstream-initiated association is represented in ASSOCIATION + objects carried in Resv messages and can be used to associate RSVP + Resv state across MPLS Tunnels/RSVP sessions. Cross-LSP association, + based on Path state, is defined in [RFC4872]. This section defines + + + +Berger, et al. Standards Track [Page 7] + +RFC 6780 RSVP Extensions October 2012 + + + cross-session association based on Resv state. This section places + no additional requirements on implementations supporting [RFC4872] + and [RFC4873]. Note, the use of an ASSOCIATION object in a single + session is not precluded. + +3.2.1. Resv Message Format + + This section provides the Backus-Naur Form (BNF), see [RFC5511], for + Resv messages containing ASSOCIATION objects. BNF is provided for + both MPLS and for non-LSP session usage. Unmodified RSVP message + formats and some optional objects are not listed. + + The formats for MPLS, GMPLS, and non-LSP sessions are identical and + are represented based on the BNF in [RFC2205] and [RFC3209]: + + ::= [ ] + + + [ ] [ ] + [ ... ] + [ ... ] +