idnits 2.17.1 draft-ietf-ccamp-rsvp-resource-sharing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-ccamp-assoc-info' is mentioned on line 155, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP F. Le Faucheur 3 Internet-Draft A. Narayanan 4 Intended status: Standards Track S. Dhesikan 5 Expires: April 21, 2011 Cisco 6 October 18, 2010 8 RSVP Resource Sharing Remote Identification Association 9 draft-ietf-ccamp-rsvp-resource-sharing-00.txt 11 Abstract 13 The RSVP ASSOCIATION object allows to create association across RSVP 14 path states or across Resv states. Two association types are 15 currently defined: recovery and resource sharing. This document 16 defines a new association type called "Resource Sharing Remote 17 Identification". It can be used by the sender to convey to the 18 receiver the information that can then be used by the receiver to 19 identify a downstream initiated resource sharing association. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 69 2. Resource Sharing Remote Identification Association . . . . . . 5 70 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. Resource Sharing Remote Identification Association Type . 8 73 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The notion of association as well as the corresponding RSVP 82 ASSOCIATION object are defined in [RFC4872] and [RFC4873] in the 83 context of GMPLS (Generalized Multi-Protocol Label Switching) 84 controlled label switched paths (LSPs). In this context, the object 85 is used to associate recovery LSPs with the LSP they are protecting. 86 This object also has broader applicability as a mechanism to 87 associate RSVP state, and [I-D.ietf-ccamp-assoc-info] defines how the 88 ASSOCIATION object can be more generally applied. [I-D.ietf-ccamp- 89 assoc-info] also reviews how the association is to be provided in the 90 context of GMPLS recovery. 92 [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 93 ASSOCIATION object. In addition, [I-D.ietf-ccamp-assoc-info] defines 94 the Extended IPv4 ASSOCIATION object and the Extended IPv6 95 ASSOCIATION object. These four forms of the ASSOCIATION object 96 contain an Association Type field that indicates the type of 97 association being identified by the ASSOCIATION object. For example, 98 Figure 1 illustrates the format of the IPv4 ASSOCIATION object. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Length | Class-Num(199)| C-Type (1) | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Association Type | Association ID | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | IPv4 Association Source | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 1: IPv4 ASSOCIATION object format 112 [RFC4872] and [RFC4873] define two association types: recovery and 113 resource sharing. Recovery type association is only applicable 114 within the context of recovery ( [RFC4872] and [RFC4873]). Resource 115 sharing is generally useful and its general use is defined in section 116 4.3.1 of [I-D.ietf-ccamp-assoc-info]. For non-recovery Usage (for 117 example for resource sharing), [I-D.ietf-ccamp-assoc-info] defines, 118 in section 4, the notion of upstream initiated association and 119 downstream initiated association. Upstream initiated association is 120 represented in ASSOCIATION objects carried in Path messages and can 121 be used to associate RSVP Path state across MPLS Tunnels / RSVP 122 sessions. Downstream initiated association is represented in 123 ASSOCIATION objects carried in Resv messages and can be used to 124 associate RSVP Resv state across MPLS Tunnels / RSVP sessions. 126 This document defines a new association type called "Resource Sharing 127 Remote Identification". 129 1.1. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Resource Sharing Remote Identification Association 137 We define here a new association type called the Resource Sharing 138 Remote Identification. 140 The Resource Sharing Remote Identification association is only 141 defined for use in upstream initiated association. Thus it can only 142 appear in ASSOCIATION objects signaled in Path messages. 144 The Resource Sharing Remote Identification association can be used by 145 the sender to convey to the receiver (inside the Association Source 146 and Association ID fields), information that can then be used by the 147 receiver to identify an upstream initiated resource sharing 148 association. This is useful in upstream initiated resource sharing 149 applications where the identification of the resource sharing 150 association is not known a priori by the receiver, and instead is 151 known by the sender (for example because the sender is in a better 152 position to assign the association identification necessary to 153 implement the desired resource sharing across RSVP sessions). 155 [I-D.ietf-ccamp-assoc-info] discusses the rules associated with the 156 processing of ASSOCIATION objects in RSVP messages. In addition to 157 generic rules applicable to all association types, a given 158 association type may define type-specific processing rules. The 159 following type-specific association rule is defined for the Resource 160 Sharing Remote Identification association type: 162 o The Resource Sharing Remote Identification association does not 163 create any association across Path states. 165 This is because the purpose of signaling an Resource Sharing Remote 166 Identification association in the downstream direction is purely to 167 convey identification information from the sender to the receiver 168 that can be used by the receiver to establish an upstream initiated 169 resource sharing association. 171 Any implementation of the present specification MUST support the 172 Resource Sharing Remote Identification association. 174 On receipt of an ASSOCIATION object whose association type is 175 Resource Sharing Remote Identification, the receiver MAY use the 176 association identification information contained in the received 177 ASSOCIATION object as the association identification information in 178 an upstream initiated resource sharing association. 180 On receipt of an ASSOCIATION object whose association type is 181 Resource Sharing Remote Identification, an RSVP receiver proxy as 182 defined in [RFC5945], SHOULD initiate an upstream initiated Resource 183 Sharing association whose association identification information is 184 copied from the received ASSOCIATION object. This behavior MAY be 185 overridden by local policy on the receiver proxy. 187 3. Security Considerations 189 TBD. 191 4. IANA Considerations 193 IANA is requested to administer assignment of new values for 194 namespaces in accordance with codepoints defined in this document and 195 summarized in this section. 197 4.1. Resource Sharing Remote Identification Association Type 199 This document defines, in Section 2, a new association type. Thus, 200 IANA is requested to allocate the following entry in the Association 201 Type registry found at 202 http://www.iana.org/assignments/gmpls-sig-parameters/ : 204 3 Resource Sharing Remote Identification (I) [this-document] 206 There are no other IANA considerations introduced by this document. 208 5. Acknowledgments 210 We thank Lou Berger for his guidance in this work and in particular 211 with respect to aligning it with the related CCAMP work on 212 Association . 214 6. References 216 6.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 222 Extensions in Support of End-to-End Generalized Multi- 223 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 224 May 2007. 226 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 227 "GMPLS Segment Recovery", RFC 4873, May 2007. 229 6.2. Informative References 231 [RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, 232 "Resource Reservation Protocol (RSVP) Proxy Approaches", 233 RFC 5945, October 2010. 235 Authors' Addresses 237 Francois Le Faucheur 238 Cisco Systems 239 Greenside, 400 Avenue de Roumanille 240 Sophia Antipolis 06410 241 France 243 Phone: +33 4 97 23 26 19 244 Email: flefauch@cisco.com 246 Ashok Narayanan 247 Cisco Systems 248 300 Beaver Brook Road 249 Boxborough, MAS 01719 250 United States 252 Email: ashokn@cisco.com 254 Subha Dhesikan 255 Cisco Systems 257 Phone: 258 Email: sdhesika@cisco.com