Internet Draft Lou Berger (LabN) Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco) Category: Standards Track Ashok Narayanan (Cisco) Expiration Date: April 14, 2011 October 14, 2010 Usage of The RSVP Association Object draft-ietf-ccamp-assoc-info-00.txt Abstract The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) 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, and this document defines how the ASSOCIATION object can be more generally applied. The document also reviews how the association is to be provided in the context of GMPLS recovery. No new new procedures or mechanisms are defined with respect to GMPLS recovery. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 14, 2011 Berger, et al Standards Track [Page 1]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 Copyright and License Notice Copyright (c) 2010 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 ........................................... 3 1.1 Conventions Used In This Document ...................... 4 2 Background ............................................. 4 2.1 LSP Association ........................................ 4 2.2 End-to-End Recovery LSP Association .................... 6 2.3 Segment Recovery LSP Association ....................... 8 2.4 Resource Sharing LSP Association ....................... 9 3 Association of GMPLS Recovery LSPs ..................... 10 4 Non-Recovery Usage ..................................... 11 4.1 Upstream Initiated Association ......................... 11 4.1.1 Path Message Format .................................... 12 4.1.2 Path Message Processing ................................ 12 4.2 Downstream Initiated Association ....................... 13 4.2.1 Resv Message Format .................................... 14 4.2.2 Resv Message Processing ................................ 14 4.3 Association Types ...................................... 15 4.3.1 Resource Sharing Association Type ...................... 15 5 Extended IPv4 and IPv6 ASSOCIATION Objects ............. 16 5.1 Extended IPv4 and IPv6 ASSOCIATION Object Format ....... 16 6 Security Considerations ................................ 18 7 IANA Considerations .................................... 18 7.1 Extended IPv4 and IPv6 ASSOCIATION Objects ............. 18 7.2 Resource Sharing Association Type ...................... 19 8 Acknowledgments ........................................ 19 9 References ............................................. 19 9.1 Normative References ................................... 19 9.2 Informative References ................................. 20 10 Authors' Addresses ..................................... 20 Berger, et al Standards Track [Page 2]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 1. Introduction End-to-end and segment recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) 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. This document provides additional narrative on how such associations are to be identified. In the context of GMPLS recovery, this document does not define any new procedures or mechanisms and is strictly informative in nature. In this context, this document formalizes the explanation provided in an e-mail to the Common Control and Measurement Plane (CCAMP) working group authored by Adrian Farrel, see [AF-EMAIL]. This document in no way modifies the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873]. In addition to the narrative, this document also explicitly expands the possible usage of the ASSOCIATION object in other contexts. In Section 4, this document reviews how association should be made in the case where the object is carried in a Path message and 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 in order 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. However, there is no way in RSVP today to share the resources between the A->B and A->C subflows of the call since by definition the RSVP reservations for these subflows must have different IP addresses in the SESSION objects. o Voice Shared Line: A single number that rings multiple endpoints (which may be geographically diverse), such as phone lines on a manager's desk and their assistant. A VoIP system that models these calls as multiple P2P unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since today unicast reservations to different endpoints cannot share bandwidth. Berger, et al Standards Track [Page 3]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 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 today, since the SESSION objects for these two flows outside the NAT would have different ports. 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. Background This section reviews the definition of LSP association in the contexts of end-to-end and segment recovery as defined in [RFC4872] and [RFC4873]. This section merely reiterates what has been defined, if differences exist between this text and [RFC4872] or [RFC4873], the earlier RFCs provide the authoritative text. 2.1. LSP Association [RFC4872] introduces the concept and mechanisms to support the association of one LSP to another LSP across different RSVP-TE sessions. Such association is enabled via the introduction of the ASSOCIATION object. The ASSOCIATION object is defined in Section 16 of [RFC4872]. It is explicitly defined as having both general application and specific use within the context of recovery. End-to- end recovery usage is defined in [RFC4872] and is covered in Section 2.2. Segment recovery usage is defined in [RFC4873] and is covered in Section 2.3. Resource sharing LSP association is also defined in [RFC4873], while strictly speaking such association is beyond the scope of this document, for completeness it is covered in Section 2.4. The remainder of this section covers generic usage of the ASSOCIATION object. In general, LSP association using the ASSOCIATION object can take place based on the values carried in the ASSOCIATION object. This means that association between LSPs can take place independent from and across different sessions. This is a significant enhancement from the association of LSPs that is possible in base MPLS [RFC3209] and GMPLS [RFC3473]. When using ASSOCIATION object, LSP association is always initiated by Berger, et al Standards Track [Page 4]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 an upstream node that inserts appropriate ASSOCIATION objects in the Path message of LSPs that are to be associated. Downstream nodes then correlate LSPs based on received ASSOCIATION objects. Multiple types of LSP association is supported by the ASSOCIATION object, and downstream correlation is made based on the type. [RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both objects have essentially the same semantics, only differing in the type of address carried (IPv4 and IPv6). The defined objects carry three fields. The three fields taken together enable the identification of which LSPs are association with one another. The three defined fields are: o Association Type: This field identifies the usage, or application, of the association object. The currently defined values are Recovery [RFC4872] and Resource Sharing [RFC4873]. This field also scopes the interpretation of the object. In other words, the type field is included when matching LSPs (i.e., the type fields must match), and the way associations are identified may be type dependent. o Association Source: This field is used to provide global scope (within the address space) to the identified association. There are no specific rules in the general case for which address should be used by a node creating an ASSOCIATION object beyond that the address is "associated to the node that originated the association", see [RFC4872]. o Association ID: This field provides an "identifier" that further scopes an association. Again, this field is combined with the other ASSOCIATION object fields to support identification of associated LSPs. The generic definition does not provide any specific rules on how matching is to be done, so such rules are governed by the Association Type. Note that the definition permits the association of an arbitrary number of LSPs. As defined, the ASSOCIATION object may only be carried in a Path message, so LSP association takes place based on Path state. The definition permits one or more objects to be present. The support for multiple objects enables an LSP to be associated with other LSPs in more than one way at a time. For example, an LSP may carry one ASSOCIATION object to associate the LSP with another LSP for end-to- end recovery, and at the same time carry a second ASSOCIATION object to associate the LSP with another LSP for segment recovery, and at the same time carry a third ASSOCIATION object to associate the LSP with yet another LSP for resource sharing. Berger, et al Standards Track [Page 5]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 2.2. End-to-End Recovery LSP Association The association of LSPs in support of end-to-end LSP recovery is defined in Section 16.2 of [RFC4872]. There are also several additional related conformance statements (i.e., use of [RFC2119] defined key words) in Sections 7.3, 8.3, 9.3, 11.1. When analyzing the definition, as with any Standards Track RFC, it is critical to note and differentiate which statements are made using [RFC2119] defined key words, which relate to conformance, and which statements are made without such key words, which are only informative in nature. As defined in Section 16.2, end-to-end recovery related LSP association may take place in two distinct forms: a. Between multiple (one or more) working LSPs and a single shared (associated) recovery LSP. This form essentially matches the shared 1:N (N >= 1) recovery type described in the other sections of [RFC4872]. b. Between a single working LSP and multiple (one or more) recovery LSPs. This form essentially matches all other recovery types described in [RFC4872]. Both forms share the same Association Type (Recovery) and the same Association Source (the working LSP's tunnel sender address). They also share the same definition of the Association ID, which is (quoting [RFC4872]): "The Association ID MUST be set to the LSP ID of the LSP being protected by this LSP or the LSP protecting this LSP. If unknown, this value is set to its own signaled LSP ID value (default). Also, the value of the Association ID MAY change during the lifetime of the LSP." The interpretation of the above is fairly straightforward. The Association ID carries one of 3 values: - The LSP ID of the LSP being protected. - The LSP ID of the LSP protecting an LSP. - In the case where the matching LSP is not yet known (i.e., initiated), the LSP ID value of the LSP itself. The text also explicitly allows for changing the Association ID during the lifetime of an LSP. But this is only an option, and is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It should be noted that the document does not describe when such a change should be initiated, or the procedures for such a change. Clearly care needs to be taken when changing the Association ID to ensure that the old association is not lost during the transition to a new association. Berger, et al Standards Track [Page 6]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 The text does not preclude, and it is therefore assumed, that one or more ASSOCIATION objects may also be added to an LSP that was originated without any ASSOCIATION objects. Again this is a case that is not explicitly discussed in [RFC4872]. From the above, this means that the following combinations may occur: Case 1. When the ASSOCIATION object of the LSP being protected is initialized before the ASSOCIATION objects of any recovery LSPs are initialized, the Association ID in the LSP being protected and any recovery LSPs will carry the same value and this value will be the LSP ID value of the LSP being protected. Case 2. When the ASSOCIATION object of a recovery LSP is initialized before the ASSOCIATION object of any protected LSP is initialized, the Association ID in the recovery LSP and any LSPs being protected by that LSP will carry the same value and this value will be the LSP ID value of the recovery LSP. Case 3. When the ASSOCIATION objects of both the LSP being protected and the recovery LSP are concurrently initialized, the value of the Association ID carried in the LSP being protected is the LSP ID value of the recovery LSP, and the value of the Association ID carried in the recovery LSP is the LSP ID value of the LSP being protected. As this case can only be applied to LSPs with matching tunnel sender addresses, the scope of this case is limited to end-to-end recovery. Note that this is implicit in [RFC4872] as its scope is limited to end-to- end recovery. In practical terms, case 2 will only occur when using the shared 1:N (N >= 1) end-to-end recovery type and case 1 will occur with all other end-to-end recovery types. Case 3 is allowed, and it is subject to interpretation how often it will occur. Some believe that this case is the common case and, furthermore, that working and recovery LSPs will often first be initiated without any ASSOCIATION objects and then case 3 objects will be added once the LSPs are established. Others believe that case 3 will rarely if ever occur. Such perspectives have little impact on interoperability as a [RFC4872] compliant implementation needs to properly handle (identify associations for) all three cases. It is important to note that Section 16.2 of [RFC4872] provides no further requirements on how or when the Association ID value is to be selected. The other sections of the document do provide further narrative and 3 additional requirements. In general, the narrative highlights case 3 identified above but does not preclude the other cases. The 3 additional requirements are, by [RFC4872] Section Berger, et al Standards Track [Page 7]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 number: o Section 7.3 -- "The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1." When considering this statement together with the 3 cases enumerated above, it can be seen that this statement clarifies which LSP ID value should be used when a single shared protection LSP is established simultaneously with (case 3), or after (case 2), more than one LSP to be protected. o Section 8.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP ID, which MUST be known before signaling of the secondary LSP." This requirement clarifies that the Rerouting without Extra- Traffic type of recovery is required to follow either case 1 or 3, but not 2, as enumerated above. o Section 9.3 -- "Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP ID, which MUST be known before signaling of the secondary LSP." This requirement clarifies that the Shared-Mesh Restoration type of recovery is required to follow either case 1 or 3, but not 2, as enumerated above. o Section 11.1 -- "In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP." This requirement clarifies that when using the LSP Rerouting type of recovery is required to follow either case 1 or 3, but not 2, as enumerated above. 2.3. Segment Recovery LSP Association GMPLS segment recovery is defined in [RFC4873]. Segment recovery reuses the LSP association mechanisms, including the Association Type field value, defined in [RFC4872]. The primary text to this effect in [RFC4873] is: 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur Berger, et al Standards Track [Page 8]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP. This statement means that case 2 as enumerated above is to be followed and furthermore that Association Source is set to the tunnel sender address of the segment recovery LSPs. The explicit exclusion of case 3 is not listed as its non-applicability was considered obvious to the informed reader. (Perhaps having this exclusion explicitly identified would have obviated the need for this document.) 2.4. Resource Sharing LSP Association Section 3.2.2 of [RFC4873] defines an additional type of LSP association which is used for "Resource Sharing". Resource sharing enables the sharing of resources across LSPs with different SESSION objects. Without this object only sharing across LSPs with a shared SESSION object was possible, see [RFC3209]. Resource sharing is indicated using a new Association Type value. As the Association Type field value is not the same as is used in Recovery LSP association, the semantics used for the association of LSPs using an ASSOCIATION object containing the new type differs from Recovery LSP association. Section 3.2.2 of [RFC4873] states the following rules for the construction of an ASSOCIATION object in support of resource sharing LSP association: - The Association Type value is set to "Resource Sharing". - Association Source is set to the originating node's router address. - The Association ID is set to a value that uniquely identifies the set of LSPs to be associated. The setting of the Association ID value to the working LSP's LSP ID value is mentioned, but using the "MAY" key word. Per [RFC2119], this translates to the use of LSP ID value as being completely optional and that the choice of Association ID is truly up to the originating node. Additionally, the identical ASSOCIATION object is used for all LSPs that should be associated using Resource Sharing. This differs from recovery LSP association where it is possible for the LSPs to carry different Association ID fields and still be associated (see case 3 in Section 2.2). Berger, et al Standards Track [Page 9]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 3. Association of GMPLS Recovery LSPs The previous section reviews the construction of an ASSOCIATION object, including the selection of the value used in the Association ID field, as defined in [RFC4872] and [RFC4873]. This section reviews how a downstream receiver identifies that one LSP is associated within another LSP based on ASSOCIATION objects. Note that in no way does this section modify the normative definitions of end-to-end and segment recovery, see [RFC4872] or [RFC4873]. As the ASSOCIATION object is only carried in Path messages, such identification only takes place based on Path state. In order to support the identification of the recovery type association between LSPs, a downstream receiver needs to be able to handle all three cases identified in Section 2.2. Cases 1 and 2 are simple as the associated LSPs will carry the identical ASSOCIATION object. This is also always true for resource sharing type LSP association, see Section 2.4. Case 3 is more complicated as it is possible for the LSPs to carry different Association ID fields and still be associated. The receiver also needs to allow for changes in the set of ASSOCIATION objects included in an LSP. Based on the [RFC4872] and [RFC4873] definitions related to the ASSOCIATION object, the following behavior can be followed to ensure that a receiver always properly identifies the association between LSPs: o Covering cases 1 and 2 and resource sharing type LSP association: For ASSOCIATION objects with the Association Type field values of "Recovery" (1) and "Resource Sharing" (2), the association between LSPs is identified by comparing all fields of each of the ASSOCIATION objects carried in the Path messages associated with each LSP. An association is deemed to exist when the same values are carried in all three fields of an ASSOCIATION object carried in each LSP's Path message. As more than one association may exist (e.g., in support of different association types or end-to- end and segment recovery), all carried ASSOCIATION objects need to be examined. o Covering case 3: Any ASSOCIATION object with the Association Type field value of "Recovery" (1) that does not yield an association in the prior comparison needs to be checked to see if a case 3 association is indicated. As this case only applies to end-to-end recovery, the first step is to locate any other LSPs with the identical SESSION object fields and the identical tunnel sender address fields as the LSP carrying the ASSOCIATION object. If such LSPs exist, a case 3 association is identified by comparing the value of the Association ID field with the LSP ID field of the other LSP. If Berger, et al Standards Track [Page 10]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 the values are identical, then an end-to-end recovery association exists. As this behavior only applies to end-to-end recovery, this check need only be performed at the egress. No additional behavior is needed in order to support changes in the set of ASSOCIATION objects included in an LSP, as long as the change represents either a new association or a change in identifiers made as described in Section 2.2. 4. Non-Recovery Usage While the ASSOCIATION object, [RFC4872], is defined in the context of 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 defines that the Association Type field is to be considered when determining association, i.e., there may be type-specific association rules. As discussed above, this is the case for Recovery type association objects. The text above, 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] and [RFC4860]. As described below association is always done based on matching either Path state or Resv state, but not Path state to Resv State. 4.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 a RSVP SESSION object, and multiple LSPs may be represented within a single tunnel.) Cross-session association based on Path state is defined in [RFC4872]. This definition is extended by this section, which defined generic association rules and usage for non-LSP uses. This section does not modify processing required to support [RFC4872] and [RFC4873], which is reviewed above in Section 3. Berger, et al Standards Track [Page 11]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 4.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 format for MPLS and GMPLS sessions is unmodified from [RFC4872], and can be represented based on the BNF in [RFC3209] as: <Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <EXPLICIT_ROUTE> ] <LABEL_REQUEST> [ <SESSION_ATTRIBUTE> ] [ <ASSOCIATION> ... ] [ <POLICY_DATA> ... ] <sender descriptor> The format for non-LSP sessions as based on the BNF in [RFC2205] is: <Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <ASSOCIATION> ... ] [ <POLICY_DATA> ... ] [ <sender descriptor> ] 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. Association type specific ordering requirements MAY be defined in the future. 4.1.2. Path Message Processing This section is based on the processing rules described in [RFC4872] and [RFC4873], which is reviewed above. These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. A node that wishes to allow downstream nodes to associate Path state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Path messages corresponding to the RSVP sessions to be associated. In the absence of Association Type-specific rules for identifying association, the included ASSOCIATION objects 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 for a discussion of Berger, et al Standards Track [Page 12]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 an example of Association Type-specific rules which are 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 sessions to be associated 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 see if it 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 three fields of the ASSOCIATION objects being compared. Processing once an association is identified is type specific and is outside the scope of this document. Note that as more than one association may exist, all ASSOCIATION objects carried in a received Path message which have supported association types MUST be compared against all Path state. Unless there is are type-specific processing rules, downstream nodes MUST forward all ASSOCIATION objects received in a Path message with any corresponding outgoing Path messages. 4.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-session association based on Path state is defined in [RFC4872]. This section defines cross-session association based on Resv state. This section places no additional requirements on implementations supporting [RFC4872] and [RFC4873]. Berger, et al Standards Track [Page 13]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 4.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 format for MPLS, GMPLS and non-LSP sessions are identical, and is represented based on the BNF in [RFC2205] and [RFC3209]: <Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <ASSOCIATION> ... ] [ <POLICY_DATA> ... ] <STYLE> <flow descriptor list> Relative ordering of ASSOCIATION objects with respect to each other as well as with respect to other objects is not currently significant. Relative ordering of ASSOCIATION objects of the same type MUST be preserved by transit nodes. Association type specific ordering requirements MAY be defined in the future. 4.2.2. Resv Message Processing This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. A node that wishes to allow upstream nodes to associate Resv state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Resv messages corresponding to the RSVP sessions to be associated. In the absence of Association Type-specific rules for identifying association, the included ASSOCIATION objects 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. 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 sessions to be associated 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. An upstream node can identify a downstream initiated association by performing the following checks. When a node receives a Resv message Berger, et al Standards Track [Page 14]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 it MUST check each ASSOCIATION object received in the Resv message to see if it 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 Resv message. To perform this matching, a node MUST examine the Resv state of all other sessions and compare the fields contained in the newly received ASSOCIATION object with the fields contained in the Resv state's ASSOCIATION objects. An association is deemed to exist when the same values are carried in all three fields of the ASSOCIATION objects being compared. Processing once an association is identified is type specific and is outside the scope of this document. Note that as more than one association may exist, all ASSOCIATION objects with support Association Types carried in a received Resv message MUST be compared against all Resv state. Unless there is are type-specific processing rules, upstream nodes MUST forward all ASSOCIATION objects received in a Resv message with any corresponding outgoing Resv messages. 4.3. Association Types Two association types are currently defined: recovery and resource sharing. Recovery type association is only applicable within the context of recovery, [RFC4872] and [RFC4873]. Resource sharing is generally useful and its general use is defined in this section. 4.3.1. Resource Sharing Association Type The resource sharing association type was defined in [RFC4873] and was defined within the context of GMPLS and upstream initiated association. This section presents a definition of the resource sharing association that allows for its use with any RSVP session type and in both Path and Resv messages. This definition is consistent with the definition of the resource sharing association type in [RFC4873] and no changes are required by this section in order to support [RFC4873]. The Resource Sharing Association Type MUST be supported by any implementation compliant with this document. The Resource Sharing Association Type is used to enable resource sharing across RSVP sessions. Per [RFC4873], Resource Sharing uses the Association Type field value of 2. ASSOCIATION objects with an Association Type with the value Resource Sharing MAY be carried in Path and Resv messages. Association for the Resource Sharing type MUST follow the procedures defined in Section 4.1.2 for upstream (Path message) initiated association and Section 4.2.1 for downstream (Resv message) initiated association. There are no type-specific association rules, processing rules, or ordering requirements. Note Berger, et al Standards Track [Page 15]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 that as is always the case with association as enabled by this document, no associations are made across Path and Resv state. Once an association is identified, resources should be shared across the identified sessions. Resource sharing is discussed in general in [RFC2205] and within the context of LSPs in [RFC3209]. 5. Extended IPv4 and IPv6 ASSOCIATION Objects [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object. As defined, these objects each contain an Association Source field and a 16-bit Association ID field. The combination of the Association Source and the Association ID uniquely identifies the association. Because the association-ID field is a 16-bit field, an association source can allocate up to 65536 different associations and no more. There are scenarios where this number is insufficient. (For example where the association identification is best known and identified by a fairly centralized entity, which therefore may be involved in a large number of associations.) This sections defines new ASSOCIATION objects to address this limitation. Specifically, the Extended IPv4 ASSOCIATION object and Extended IPv6 ASSOCIATION object are defined below. Both new objects include an extended association ID field, which allows identification of a larger number of associations scoped within a given association source IP address. The Extended IPv4 ASSOCIATION object and Extended IPv6 ASSOCIATION object SHOULD be supported by an implementation compliant with this document. The processing rules for the Extended IPv4 and IPv6 ASSOCIATION object are identical to those of the existing IPv4 and IPv6 ASSOCIATION objects. 5.1. Extended IPv4 and IPv6 ASSOCIATION Object Format The Extended IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the format: Berger, et al Standards Track [Page 16]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 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(199)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID (Continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) has the format: 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(199)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID (Continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Association Type: 16 bits Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Association ID: 48 bits Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. (Only the size of this field differs from the [RFC4872] definition.) Association Source: 4 or 16 bytes Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Berger, et al Standards Track [Page 17]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 6. Security Considerations A portion of this document reviews procedures defined in [RFC4872] and [RFC4873] and does not define any new procedures. As such, no new security considerations are introduced in this portion. Section 4 defines broader usage of the ASSOCIATION object, but does not fundamentally expand on the association function that was previously defined in [RFC4872] and [RFC4873]. Section 5 increases the number of bits that are carried in an ASSOCIATION object (by 32), and similarly does not expand on the association function that was previously defined. This broader definition does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried in RSVP. Therefore there are no new risks or security considerations introduced by this document. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 7. IANA Considerations IANA is requested to administer assignment of new values for namespaces defined in this document and summarized in this section. 7.1. Extended IPv4 and IPv6 ASSOCIATION Objects Upon approval of this document, IANA will make the assignment of two new C-Types (which are defined in section 5.1) for the existing ASSOCIATION object in the "Class Names, Class Numbers, and Class Types" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp- parameters: 199 ASSOCIATION [RFC4872] Class Types or C-Types 3 Type 3 Extended IPv4 Association [this document] 4 Type 4 Extended IPv6 Association [this document] Berger, et al Standards Track [Page 18]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 7.2. Resource Sharing Association Type This document also broadens the potential usage of the Resource Sharing Association Type defined in [RFC4873]. As such, IANA is requested to change the Reference of the Resource Sharing Association Type included in the associate registry. This document also directs IANA to correct the duplicate usage of '(R)' in this Registry. In particular, the Association Type registry found at http://www.iana.org/assignments/gmpls-sig-parameters/ should be updated as follows: OLD: 2 Resource Sharing (R) [RFC4873] NEW 2 Resource Sharing (S) [RFC4873][this-document] There are no other IANA considerations introduced by this document. 8. Acknowledgments This document formalizes the explanation provided in an e-mail to the working group authored by Adrian Farrel, see [AF-EMAIL]. The document was written in response to questions raised in the CCAMP working group by Nic Neate <nhn@dataconnection.com>. Valuable comments and input was also received from Dimitri Papadimitriou. We thank Subha Dhesikan for her contribution to the early work on sharing of resources across RSVP reservations. 9. References 9.1. Normative References [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., "GMPLS Segment Recovery", RFC 4873, May 2007. Berger, et al Standards Track [Page 19]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 [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. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009 9.2. Informative References [AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of the Association ID", CCAMP working group mailing list, http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html, November 18, 2008. [RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M., "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5920] Fang, L., et al, "Security Framework for MPLS and GMPLS Networks", work in progress, RFC 5920, July 2010. 10. Authors' Addresses Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Berger, et al Standards Track [Page 20]
Internet-Draft draft-ietf-ccamp-assoc-info-00.txt October 14, 2010 Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France Email: flefauch@cisco.com Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States Email: ashokn@cisco.com Berger, et al Standards Track [Page 21]
Generated on: Thu, Oct 14, 2010 3:20:05 PM
