idnits 2.17.1 draft-gray-mpls-rsvp-oif-uni-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-06 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-lang-mpls-lmp-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Duplicate reference: draft-kompella-ospf-ompls-extensions, mentioned in '7', was also mentioned in '6'. -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eric Gray, Fong Liaw, John Yu 2 Internet Draft Zaffire 3 Expiration Date: February 2001 John Drake, Jonathan Lang 4 Calient Networks 5 Yakov Rekhter, George Swallow 6 Cisco Systems 7 Kireeti Kompella 8 Juniper Networks 9 Bala Rajagopolan 10 Tellium 11 Raj Jain 12 Nayna Networks 13 Osama Aboul-Maged 14 Nortel Networks 15 Greg Bernstein 16 Ciena 17 Zhensheng Zhang 18 Sorrento Networks 20 July, 2000 22 RSVP Extensions in Support of OIF Optical UNI Signaling 23 draft-gray-mpls-rsvp-oif-uni-ext-00.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026 [1]. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference material 37 or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 This draft defines a signaling mechanism based on RSVP-TE ([2]) to 48 support an Optical User Network Interface (UNI). This effort is in 49 part driven by work in the OIF as well as the recent draft on 50 signaling requirements for the optical UNI ([3]), and is consistent 51 with recent work on Generalized MPLS (see [4], [5], [6], and [7]). 52 The main function of this draft is to identify the relevant mechanisms 53 in RSVP-TE (including further extensions) to satisfy functional 54 requirements for an Optical UNI. This draft reflects ongoing work at 55 the Optical Interworking Forum (OIF), however, not all of the 56 concepts/requirements have been approved by the OIF. 58 1. Introduction 60 There has recently been a significant effort amongst carriers, service 61 providers, and vendors in the optical networking space to eliminate 62 proprietary control protocols and develop a common control plane. 63 The Optical Internetworking Forum (OIF) has initiated work on an 64 Optical User-Network Interface (Optical UNI) as a step in this 65 direction. Recently, a draft [3] was submitted to the IETF defining 66 proposed requirements and abstract messages for the Optical UNI. 68 This document describes how a signaling mechanism based on RSVP-TE [2] 69 may be used for an Optical UNI. In particular, we identify the 70 mechanisms already defined for RSVP-TE that can be used to satisfy the 71 proposed requirements of [3]. This work is also based on recent 72 Internet Drafts defining Generalized MPLS signaling (e.g. - [4]). 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [8]. 78 2. Overview 80 RSVP-TE is one of the candidate protocols described in [3] for Optical 81 UNI signaling implementation. As part of this Optical UNI, the 82 signaling protocol must have the capability to create, delete, and 83 modify lightpaths across a network, as well as query the status of an 84 existing lightpath. Most of these capabilities may be directly 85 supported by re-using existing procedures, messages, and objects 86 defined in RSVP-TE [2] and in Generalized MPLS Signaling [4]. 88 This document further extends [2] and [4] to support Optical UNI 89 signaling requirements as following: 91 - Use of DREQ and DREP message and procedure as defined in [9] for 92 Lightpath status enquiry and response. 94 - Use of Message_ID and Message_Ack objects, Ack_desire flag, and 95 Ack message as defined in [10] to support confirmation of Lightpath 96 deletion and reliable messaging. 98 - PathTear and ResvTear MUST be used to delete a lightpath. 100 This specification does not specify procedures to support the 101 following proposed requirements listed in [3]: 103 - Concept of "indirect interface" as defined in [3]. It is 104 envisioned that such a requirement can be better serviced 105 via a network management station. 107 - Different source and destination user groups. Instead, this 108 specification allows specifying a single user group using 109 resource affiliation defined in [2]. 111 - Procedures for client registration. 113 2.1 Use of RSVP-TE and Generalized MPLS signaling for Optical UNI 115 2.1.1 In-band and out-of-band signaling channels 117 Optical UNI requires support of in-band and out-of-band signaling 118 channels. The in-band signaling channel is supported by the use of 119 a regular link; and the concept of out-of-band signaling channel 120 is supported by the use of bundled links [8] where a bundled link 121 consists of a control channel and one or more component links. 123 When out-of-band signaling channel is used, the procedure, 124 messages, and objects apply to a bundled link as defined in [4], 125 [11], [12], and [5] shall be used. 127 2.1.2 Reliable messaging 129 To support reliable messaging across the UNI, the Message_ID and 130 Message_Ack objects, Ack message, and Ack desired flag of [10] MUST 131 be used in UNI RSVP messages. Acknowledgements apply to hop-by-hop, 132 as opposed to end-to-end, message delivery. 134 2.1.2 Lightpath creation 136 Lightpath creation uses the procedure described in section 2.2 137 "Operation of LSP tunnels" of [2]. Additional objects and their use 138 and procedure are defined in Sections 3 and 4 of [4]. 140 2.1.3 Lightpath modification 142 Lightpath modification uses procedure as described in section 2.5 143 "Rerouting of Traffic Engineered Tunnels" of [2]. 145 2.1.4 Lightpath deletion 147 Lightpath deletion can be done by either the client that originated 148 or terminated the lightpath. The lightpath originator will use the 149 PathTear message while the lightpath terminator will use the ResvTear 150 message. Acknowledgement mechanisms of [10] MUST be used to provide 151 confirmation. 153 2.1.5 Lightpath status enquiry and response 155 Any client interested in the lightpath status shall send a Diagnostic 156 Request (DREQ) message toward the termination end point of the 157 lightpath. The DREQ message specifies the Session Object, Sender 158 Template Object, and an ending node. Starting at the last hop of the 159 lightpath, the DREQ message is sent along the lightpath toward the 160 sender and start collecting information hop-by-hop in the DREQ. When 161 the DREQ message reaches the ending node, the message type is changed 162 to Diagnostic Reply (DREP) and forwarded to the original requestor 163 node. The DREQ originator can select specific RSVP objects to be 164 collected by including a DIAG_SELECT object in the DREQ message. The 165 full procedure of DREQ and DREP messages is described in [9]. 167 3. RSVP Message Extensions for OPTICAL UNI signaling 169 In addition to objects defined in [2] and [4], new objects may need to 170 be defined to address additional requirements. Additional objects 171 defined in this specification are OPTIONAL with respect to RSVP and 172 RSVP-TE. 174 3.1 Propagation Delay Object 176 If a propagation delay is desired, the lightpath originator shall 177 include a Propagation_Delay_object and an ADSPEC object in its Path 178 Message for the lightpath. Network nodes along the lightpath must 179 update the ADSPEC and compare the result with the propagation delay 180 object. If the result is comformant, the node shall forward the Path 181 message downstream. Otherwise, it shall generate a PathErr message 182 carrying error code "XXX" (TBD) and discard the Path message. 184 3.2 Labels 186 Generalized MPLS signaling [4] defines several types of labels that 187 may be represented in a Generalized Label object. For Optical 188 applications a label may be arbitrarily associated with all or part 189 of a component link, or may be a superset of multiple component 190 links. A common understanding of the meaning of a Generalized Label 191 - in particular the meaning of the link ID portion of the 192 Generalized Label - must exist between the user and the network 193 across any Optical UNI. This common understanding may be dynamically 194 derived (e.g. using LMP [5]), or it may be configured. 196 This specification uses the Generalized Label, Generalized Label 197 Request, Upstream Label, Suggested Label and Label Set objects 198 defined in [4]. 200 4. RSVP objects related to OPTICAL signaling requirements 202 Optical UNI signaling requirements [3] specify a set of attributes to 203 be signaled during lightpath creation and modification. The following 204 table summarizes the RSVP objects that are used to signaling a 205 particular OPTICAL signaling attribute. 207 OPTICAL signaling attribute RSVP object 208 ------------------------------+------------------------------- 209 Light_Path ID | Session [2] 210 Source termination point | Sender Template (or Session) [2] 211 Destination termination point | Session [2] 212 Source Termination Point Port | Label Set/Suggest Label [4] 213 Destination Termination Label | Egress Label [4] 214 Contract ID | Session Attribute/Name [2] 215 Framing | Generalized Label Request [4] 216 Bandwidth | Generalized Label Request [4] 217 Transparency | Generalized Label Request [4] 218 Directionality | Upstream Label [4] 219 Service Level | Session Attribute [2] 220 Diversity | Session Attribute [2] 221 | and Generalized Label Request 222 | Object [4] 223 Return code | Error Spec 224 Source user group ID | Session Attributes/LSP_TUNNEL_RA [2] 225 Destination user group ID | Session Attributes/LSP_TUNNEL_RA [2] 226 Propagation Delay | Propagation Delay (TBD) 227 ------------------------------+--------------------------------- 229 5. RSVP messages related to OPTICAL UNI signaling 231 5.1 Path Message 233 As described in [4], RSVP-TE signaling for support of lightpath 234 creation allows for labels to be suggested by the upstream LSR 235 that is sending a Path message. In addition, the upstream node 236 may provide a label for use in bi-directional setup. The format 237 for the Path message to be used for the OPTICAL UNI is given below. 239 ::= [ ] 240 241 [ ] 242 [ ] 243 244 [