idnits 2.17.1 draft-ietf-ccamp-rsvp-resource-sharing-01.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 (March 9, 2011) is 4798 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) == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-assoc-info-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-assoc-info (ref. 'I-D.ietf-ccamp-assoc-info') ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-rsvp-proxy-approaches (ref. 'I-D.ietf-tsvwg-rsvp-proxy-approaches') Summary: 2 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: September 10, 2011 Cisco 6 March 9, 2011 8 RSVP Resource Sharing Remote Identification Association 9 draft-ietf-ccamp-rsvp-resource-sharing-01.txt 11 Abstract 13 The Resource reSerVation Protocol (RSVP) ASSOCIATION object allows to 14 create association across RSVP path states or across Resv states. 15 Two association types are currently defined: recovery and resource 16 sharing. This document defines a new association type called 17 "Resource Sharing Remote Identification". It can be used by the 18 sender to convey to the receiver the information that can then be 19 used by the receiver to identify a downstream initiated resource 20 sharing association. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 70 2. Resource Sharing Remote Identification Association . . . . . . 6 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Resource Sharing Remote Identification Association Type . 9 74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 The notion of association as well as the corresponding RSVP 81 ASSOCIATION object are defined in [RFC4872] and [RFC4873] in the 82 context of GMPLS (Generalized Multi-Protocol Label Switching) 83 controlled label switched paths (LSPs). In this context, the object 84 is used to associate recovery LSPs with the LSP they are protecting. 85 This object also has broader applicability as a mechanism to 86 associate RSVP state, and [I-D.ietf-ccamp-assoc-info] defines how the 87 ASSOCIATION object can be more generally applied. 88 [I-D.ietf-ccamp-assoc-info] also reviews how the association is to be 89 provided in the context of GMPLS recovery. 91 [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 92 ASSOCIATION object. In addition, [I-D.ietf-ccamp-assoc-info] defines 93 the Extended IPv4 ASSOCIATION object and the Extended IPv6 94 ASSOCIATION object. These four forms of the ASSOCIATION object 95 contain an Association Type field that indicates the type of 96 association being identified by the ASSOCIATION object. For example, 97 Figure 1 illustrates the format of the IPv4 ASSOCIATION object. 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Length | Class-Num(199)| C-Type (1) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Association Type | Association ID | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | IPv4 Association Source | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 Figure 1: IPv4 ASSOCIATION object format 111 [RFC4872] and [RFC4873] define two association types: recovery and 112 resource sharing. Recovery type association is only applicable 113 within the context of recovery ( [RFC4872] and [RFC4873]). Resource 114 sharing is useful in multiple contexts and its general use is defined 115 in section 4.3.1 of [I-D.ietf-ccamp-assoc-info]. For non-recovery 116 usage (for example for resource sharing), [I-D.ietf-ccamp-assoc-info] 117 defines, in section 4, the notion of upstream initiated association 118 and downstream initiated association. Upstream initiated association 119 is represented in ASSOCIATION objects carried in Path messages and 120 can be used to associate RSVP Path state across MPLS Tunnels or RSVP 121 sessions. Downstream initiated association is represented in 122 ASSOCIATION objects carried in Resv messages and can be used to 123 associate RSVP Resv state across MPLS Tunnels or RSVP sessions. 125 This document defines a new association type called "Resource Sharing 126 Remote Identification". 128 1.1. Conventions Used in This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Resource Sharing Remote Identification Association 136 We define here a new association type called the Resource Sharing 137 Remote Identification. 139 The Resource Sharing Remote Identification association type can be 140 used with the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object 141 defined in [RFC4872] as well as with the Extended IPv4 ASSOCIATION 142 object and the Extended IPv6 ASSOCIATION object defined in 143 [I-D.ietf-ccamp-assoc-info]. 145 The Resource Sharing Remote Identification association is only 146 defined for use in upstream initiated association. Thus it can only 147 appear in ASSOCIATION objects signaled in Path messages. 149 The Resource Sharing Remote Identification association can be used by 150 the sender to convey to the receiver (inside the Association Source 151 and Association ID fields), information that can then be used by the 152 receiver to identify an upstream initiated resource sharing 153 association. This is useful in upstream initiated resource sharing 154 applications where the identification of the resource sharing 155 association is not known a priori by the receiver, and instead is 156 known by the sender (for example because the sender is in a better 157 position to assign the association identification necessary to 158 implement the desired resource sharing across RSVP sessions). 160 [I-D.ietf-ccamp-assoc-info] discusses the rules associated with the 161 processing of ASSOCIATION objects in RSVP messages. In addition to 162 generic rules applicable to all association types, a given 163 association type may define type-specific processing rules. The 164 following type-specific association rule is defined for the Resource 165 Sharing Remote Identification association type: 167 o The Resource Sharing Remote Identification association does not 168 create any association across Path states. 170 This is because the purpose of signaling an Resource Sharing Remote 171 Identification association in the downstream direction is purely to 172 convey identification information from the sender to the receiver 173 that can be used by the receiver to establish an upstream initiated 174 resource sharing association. 176 Any implementation of the present specification MUST support the 177 Resource Sharing Remote Identification association. 179 On receipt of an ASSOCIATION object whose association type is 180 Resource Sharing Remote Identification, the receiver MAY use the 181 association identification information contained in the received 182 ASSOCIATION object as the association identification information in 183 an upstream initiated resource sharing association. 185 On receipt of an ASSOCIATION object whose association type is 186 Resource Sharing Remote Identification, an RSVP receiver proxy as 187 defined in [I-D.ietf-tsvwg-rsvp-proxy-approaches], SHOULD initiate an 188 upstream initiated Resource Sharing association whose association 189 identification information is copied from the received ASSOCIATION 190 object. This behavior MAY be overridden by local policy on the 191 receiver proxy. 193 3. Security Considerations 195 TBD. 197 4. IANA Considerations 199 IANA is requested to administer assignment of new values for 200 namespaces in accordance with codepoints defined in this document and 201 summarized in this section. 203 4.1. Resource Sharing Remote Identification Association Type 205 This document defines, in Section 2, a new association type. Thus, 206 IANA is requested to allocate the following entry in the Association 207 Type registry found at 208 http://www.iana.org/assignments/gmpls-sig-parameters/ : 210 3 Resource Sharing Remote Identification (I) [this-document] 212 There are no other IANA considerations introduced by this document. 214 5. Acknowledgments 216 We thank Lou Berger for his guidance in this work and in particular 217 with respect to aligning it with the related CCAMP work on 218 Association . 220 6. Normative References 222 [I-D.ietf-ccamp-assoc-info] 223 Berger, L., Faucheur, F., and A. Narayanan, "Usage of The 224 RSVP Association Object", draft-ietf-ccamp-assoc-info-00 225 (work in progress), October 2010. 227 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 228 Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP 229 Proxy Approaches", 230 draft-ietf-tsvwg-rsvp-proxy-approaches-09 (work in 231 progress), March 2010. 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 237 Extensions in Support of End-to-End Generalized Multi- 238 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 239 May 2007. 241 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 242 "GMPLS Segment Recovery", RFC 4873, May 2007. 244 Authors' Addresses 246 Francois Le Faucheur 247 Cisco Systems 248 Greenside, 400 Avenue de Roumanille 249 Sophia Antipolis 06410 250 France 252 Phone: +33 4 97 23 26 19 253 Email: flefauch@cisco.com 255 Ashok Narayanan 256 Cisco Systems 257 300 Beaver Brook Road 258 Boxborough, MAS 01719 259 United States 261 Email: ashokn@cisco.com 263 Subha Dhesikan 264 Cisco Systems 266 Phone: 267 Email: sdhesika@cisco.com