idnits 2.17.1 draft-aboulmagd-mpls-ldp-optical-uni-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 64 lines 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 243 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), 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) -- Missing reference section? '1' on line 271 looks like a reference -- Missing reference section? '2' on line 406 looks like a reference -- Missing reference section? '3' on line 62 looks like a reference -- Missing reference section? '4' on line 270 looks like a reference -- Missing reference section? '5' on line 159 looks like a reference -- Missing reference section? '6' on line 357 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Osama Aboul-Magd 3 Internet Draft Nortel Networks 4 Raj Jain 5 draft-aboulmagd-mpls-ldp-optical-uni-00.txt Nayna Networks 6 Expiration Date: January 2001 LianYu Jia 7 ONI Systems 8 Bala Rajagopalan 9 Tellium Inc. 10 Robert Rennison 11 Laurel Networks 12 Yangguang Xu 13 Lucent Tech 14 Zhensheng Zhang 15 Sorrento Networks 17 July, 2000 19 LDP Extensions for Optical User Network Interface (O-UNI) Signaling 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with all 24 provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering Task 27 Force (IETF), its areas, and its working groups. Note that other groups 28 may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet- Drafts as reference material 33 or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 1. Abstract 42 General requirements for signaling across the Optical UNI (O-UNI) are 43 discussed in [1]. This draft describes extensions to the LDP protocol 44 [2] to support those requirements. The LDP extensions described here 45 address two areas: 47 - The addition of new TLVs to support the attributes required for 48 lightpath establishment at the O-UNI 50 Aboul-Magd January 2001 1 51 - Two new LDP messages to allow for the exchange of lightpath status 52 information across the UNI. 54 The content of this draft is expected to evolve as work progresses on 55 the optical UNI. This draft is a work in progress. 57 2. Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [3]. 63 3. Use of LDP for the O-UNI 65 This draft describes how LDP with extensions may be used as a signaling 66 mechanism for the O-UNI. Several O-UNI abstract messages are defined in 67 [1]. This draft shows how to use the existing LDP messages for that 68 purpose. Two new LDP messages are introduced to meet the requirements 69 for the exchange of status information across the O-UNI 71 3.1. Overview 73 LDP is one of the candidate protocols described in [1] for an O-UNI 74 signaling implementation. 76 Applying LDP at the O-UNI allows for: 78 - The reuse of already defined LDP messages and message formats 79 - The reuse of LDP session management and control procedures 80 - Additions to the already specified procedures for notification 81 of errors. 82 - The reuse of the LDP security mechanism 84 Support for the O-UNI signaling requirements depends upon the use of 85 the following LDP behaviors and mechanisms as defined in [2]. 87 - Use of Basic and/or Extended discovery mechanisms. 88 - Use of the Label Request Message in downstream on demand label 89 advertisement mode with ordered control. 90 - Use of the Label Mapping Message in downstream on demand label 91 advertisement mode with ordered control. 92 - Use of the Notification Message. 93 - Use of the Withdraw and Release Messages. 95 Additional messages are defined to support the propagation of lightpath 96 status information as defined in [1]. 98 Aboul-Magd January 2001 2 99 Additional TLVs are specified to support the lightpath attributes 100 specified in [1]. Note: Additional work is required to define the 101 format of these TLVs. 103 3.2. Use of LDP Messages for O-UNI 105 A set of abstract UNI messages is defined in [1]. Those abstract 106 messages support the basic functions of the optical UNI. Those 107 functions are, lightpath create, lightpath delete, lightpath 108 modification, and lightpath status enquiry. Each of those functions is 109 supported by a set of messages. 111 The procedures for handling LDP messages across the optical UNI are 112 unchanged with the exception that: 114 The LDP FEC TLV SHOULD be ignored since it is not applicable at 115 the UNI. 117 Note: The use of LDP messages for the optical UNI does not change the 118 semantics of the LDP Message ID. 120 3.2.1. Lightpath Create Action 122 For the lightpath create action, [1] defines two abstract messages, the 123 lightpath Create Request and the Lightpath Create Response. The mapping 124 of the LDP messages to fulfill the lightpath create action is: 126 - Lightpath Create Request: The create request function is 127 achieved by the LDP Label Request Message. The Generalized Label 128 Request TLV defined in [4] is used to convey the lightpath 129 attributes to the network side. 130 - Lightpath Create Response: The create response function is 131 achieved by the use of the LDP Label Mapping Message. The create 132 response function makes use of the Generalized label defined in 133 [4]. The Label Mapping procedures are limited to downstream on 134 demand, ordered control mode with conservative label retention 135 mode. 137 3.2.2. Lightpath Delete Action 139 For the lightpath delete action, [1] defines two abstract messages, 140 the Lightpath Delete Request and the Lightpath Delete Response. The 141 mapping of the LDP messages to fulfill the function of the lightpath 142 delete action is: 144 - Lightpath Delete Request: The delete request is achieved by the 145 LDP Label Release Request Message. The Label Release Message is 147 Aboul-Magd January 2001 3 148 sent from the initiating client at any time depending on his 149 need for the lightpath. 150 - Lightpath Delete Response: The delete Response is achieved by 151 the LDP Label Withdraw Message. 153 3.2.3. Lightpath Modify Action 155 For the Lightpath modify action, [1] defines two abstract messages, The 156 Lightpath Modification Request and the Lightpath Modification Response. 158 Lightpath modify action does not require the definition of new LDP 159 message. The modify action follows the procedure described in [5]. 161 3.2.4. Lightpath Status Enquiry Action 163 For the lightpath status enquiry action, [1] defines two abstract 164 messages, Lightpath Status Enquiry and Lightpath Status Response 166 The Lightpath Status Enquiry and Lightpath Status Response functions 167 require the definition of two new LDP messages, The Status Enquiry 168 Message and the Status Response Message. The encoding of the new 169 messages is defined in the next section. 171 When an LSR receives a Status Enquiry message it generates an LDP 172 Status Response Message. The Status Response message is useful for 173 lightpath recovery after failure, it contains the attributes of 174 lightpaths that are affected by failure. 176 3.2.5. Notification Action 178 The Notification function is similar in scope to that of the LDP 179 Notification Message. Hence the LDP Notification message is used across 180 the optical UNI for this purpose. 182 4. LDP Message Extensions 184 4.1. Label Request Message 186 Additional TLVs are added to the LDP Label Request Message as shown 187 below: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |0| Label Request (0x0401) | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Message ID | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | FEC TLV | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Aboul-Magd January 2001 4 200 | Generalized Label Request TLV | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Source Termination Point TLV (O-UNI mandatory) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Destination Termination Point TLV (O-UNI mandatory) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Source User Group ID TLV (O-UNI mandatory) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Destination User Group ID TLV (O-UNI mandatory) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Contract ID TLV (O-UNI mandatory) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Transparency TLV (O-UNI mandatory) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Propagation Delay (optional) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Lightpath Schedule TLV (optional) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Reserved |D|Service Level|| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Diversity TLV (optional) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Propagation Delay (optional) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Optional Parameters | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 The Generalized Label TLV is as defined in [4]. The generalized Label 228 Request TLV carries information regarding the span protection type, the 229 lightpath encoding and bandwidth. Additional TLVs are added to the 230 Label Request Message to accommodate lightpath attributes defined in 231 [1]. D specifies the lightpath directionality as specified in [1]. 233 4.2. Label Mapping Message 235 Additional TLVs are added to the LDP Label Mapping Message as shown 236 below: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |0| Label Mapping (0x0400) | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Message ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | FEC TLV | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Generalized Label TLV | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Lightpath ID TLV(O-UNI mandatory) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Aboul-Magd January 2001 5 253 | Source Termination Point TLV (O-UNI mandatory) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Destination Termination Point TLV (O-UNI mandatory | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Source User Group ID TLV (O-UNI mandatory) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Destination User Group ID TLV (O-UNI mandatory) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Contract ID TLV (O-UNI mandatory) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved |D|Service Level|| 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Result Code TLV (O-UNI mandatory) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Optional Parameters | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 The Generalized Label TLV is as defined in [4]. The rest of the 271 attributes are as defined in [1]. The Result code TLV reflects the 272 result of the lightpath create process. 274 4.3. The Label Release Message 276 The LightPath TLV is added to the LDP Label Release Message as shown 277 below: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |0| Label Release (0x0403) | Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Message ID | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | FEC TLV | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Lightpath ID TLV (O-UNI mandatory) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Optional Parameters | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 4.4. The Label Withdraw Message 295 Additional TLVs are added to the LDP Label WithDraw Message as shown 296 below: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |0| Label Withdraw (0x0402) | Length | 303 Aboul-Magd January 2001 6 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Message ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | FEC TLV | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Lightpath ID TLV (O-UNI mandatory) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Result Code TLV (O-UNI mandatory) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Optional Parameters | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 4.5. The Notification Message 318 The encoding for the Notification Message is: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |0| Notification (0x0001) | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Message ID | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Lightpath ID (O-UNI mandatory) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Status TLV | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Optional Parameters | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 The Status TLV is as defined in [2]. New status codes will be added to 335 reflect the state of the lightpath. 337 4.6. The Status Enquiry Message 339 The Status Enquiry Message is a new LDP message. The encoding for the 340 Status Enquiry Message is: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |0| Status Enquiry (0x0002) | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Message ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Lightpath ID TLV | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | UNI-C ID TLV | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Optional Parameters | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Aboul-Magd January 2001 7 357 The UNI-C is as defined in [6]. The Lightpath ID TLV is optional in the 358 Status Enquiry Message. The UNI-C ID TLV is an O-UNI mandatory 359 parameter if the Lightpath ID TLV does not exist. Otherwise, it is 360 optional. 362 4.7. The Status Response Message 364 The Status Response Message is a new LDP message. The encoding for the 365 Status Response Message is: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |U|F| 0x0003 | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Message ID | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Lightpath ID TLV | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Source Termination Point TLV (optional) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Destination Termination Point TLV (optional ) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Source User Group ID (optional) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Destination User Group ID (optional) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Contract ID TLV (optional) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Transparency TLV (optional) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Propagation Delay (optional) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Lightpath Schedule TLV (optional) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Reserved |D|Service Level| | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Diversity TLV (optional) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Propagation Delay (optional) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Status TLV (O-UNI mandatory) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Optional Parameters | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 5. Security Considerations 405 Aboul-Magd January 2001 8 406 This draft has the same security consideration as in [2]. 408 6. References 410 1 Rajagopalan, B. et. al., "Signaling Requirements at the IP-Optical 411 Interface (UNI)" draft-bala-mpls-uni-signaling-00.txt, work in 412 progress, July 2000. 414 2 Andersson, L., et. al., "LDP Specifications_, draft-ietf-mpls-ldp- 415 08.txt, work in progress, June 2000 417 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 418 Levels", BCP 14, RFC 2119, March 1997 420 4 P. Ashwood-Smith, "MPLS Optical/Switching Signaling Functional 421 Description_ IETF Draft, Work in Progress, June 2000. 423 5 Ash, J., et, al., "LSP Modification Using CR-LDP", draft-ietf-mpls- 424 crlsp-modify-01.txt, work in progress, Feb. 2000. 426 6 K. Bala, et. al., "User Network Interface 1.0 Proposal " OIF 427 Contribution, OIF2000.125, June 2000. 429 Aboul-Magd January 2001 9 430 7. Author's Addresses 432 Raj Jain 433 Nayna Networks, Inc. 434 157 Topaz St. 435 Milpitas, CA 95035 436 Phone: 408-956-8000x309 437 Fax: 408-956-8730 438 Email:raj@nayna.com 440 Zhensheng Zhang 441 Sorrento Networks 442 9990 Mesa Rim Road 443 San Diego, CA 92121 444 Tel: 858-646-7195 445 e.mail:zzhang@sorrentonet.com 447 Robert Ronnison 448 Laurel Networks 449 2607 Nicholson Road 450 Sewickley, PA 15143, USA 451 Tel: +1 724-933-7330 452 Email:robren@laurelnetworks.com 454 Osama S. Aboul-Magd 455 Nortel Networks 456 P.O. Box 3511, Station _C_ 457 Ottawa, Ont, K1Y-4H7 458 Tel : 613-763-5827 459 e.mail :osama@nortelnetworks.com 461 Bala Rajagopalan 462 Tellium, Inc. 463 2 Crescent Place 464 Ocean Port, NJ 07757 465 Email :braja@tellium.com 467 Liangyu Jia 468 ONI Systems Corp. 469 166 Baypoints Parkway 470 San Jose, CA 95134 471 Tel: 408-965-2743 472 Fax: 408-965-2660 473 e.mail:ljia@oni.com 475 Yangguang Xu 476 Lucent Technologies Inc. 477 21-2A41 478 1600 Osgood St. 479 N. Anderson, MA 01845 480 Tel : 978-960-6105 481 e.mail :xuyg@Lucent.com 482 Full Copyright Statement 484 "Copyright (C) The Internet Society (date). All Rights Reserved. 485 This document and translations of it may be copied and furnished to 486 others, and derivative works that comment on or otherwise explain it 487 or assist in its implementation may be prepared, copied, published 488 and distributed, in whole or in part, without restriction of any 489 kind, provided that the above copyright notice and this paragraph 490 are included on all such copies and derivative works. However, this 491 document itself may not be modified in any way, such as by removing 492 the copyright notice or references to the Internet Society or other 493 Internet organizations, except as needed for the purpose of 494 developing Internet standards in which case the procedures for 495 copyrights defined in the Internet Standards process must be 496 followed, or as required to translate it into