idnits 2.17.1 draft-ietf-mpls-ldp-optical-uni-00.txt: ** The Abstract section seems to be numbered -(124): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(792): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(795): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(884): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(891): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(897): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(900): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 17) being 66 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 388 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 135 looks like a reference -- Missing reference section? '2' on line 824 looks like a reference -- Missing reference section? '3' on line 61 looks like a reference -- Missing reference section? '4' on line 569 looks like a reference -- Missing reference section? '5' on line 211 looks like a reference -- Missing reference section? '7' on line 574 looks like a reference -- Missing reference section? '6' on line 325 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 5 draft-ietf-mpls-ldp-optical-uni-00.txt Raj Jain 6 Expiration Date: April 2001 Nayna Networks 7 LiangYu Jia 8 ONI Systems 9 Bala Rajagopalan 10 Tellium 11 Robert Rennison 12 Laurel Networks 13 Yangguang Xu 14 Lucent Tech 15 Zhensheng Zhang 16 Sorrento Networks 17 October, 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 April 2001 1 51 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 53 - Two new LDP messages to allow for the exchange of lightpath status 54 information across the UNI. 56 2. Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [3]. 62 3. Use of LDP for the O-UNI 64 This draft describes how LDP with extensions will be used as a 65 signaling mechanism for the O-UNI. Several O-UNI abstract messages are 66 defined in [1]. This draft specifies how to use the existing LDP 67 messages for that purpose. Two new LDP messages are introduced to meet 68 the requirements for the exchange of status information across the O- 69 UNI. 71 3.1. Overview 73 LDP is one of the candidate protocols described in [1] for 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 of 81 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 Additional TLVs are specified to support the lightpath attributes 99 specified in [1]. 101 Aboul-Magd April 2001 2 102 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 104 4. O-UNI Session Management and Control 106 LDP messages that relevant to the O-UNI session management and control 107 are Hello Message, Initialization Message, and KeepAlive Message. 109 4.1. Hello Message 111 This draft does not change the format or the procedures of the LDP 112 Hello Message as described in section 3.5.2. of [2]. 114 4.2. KeepAlive Message 116 This draft does not change the format or the procedures of the LDP 117 KeepAlive Message as defined in section 3.5.4 of [2]. 119 4.3. Initialization Message 121 The Initilaization Message is as defined in section 3.5.3 of [2] with 122 the following modifications: 124 - The Label Advertisement Discipline (the �A� bit) is always set at 1 125 to indicate Downstream on Demand label distribution mode. Downstream on 126 Demand is the only label distribution mode supported at the O-UNI. The 127 assignment A=0 should result in generating a Notification Message with 128 the appropriate error code. 129 - Loop Detection is always disabled, D=0. The assignment D=1 should 130 result in generating a Notification Message with the appropriate error 131 code. 133 5. The Use of LDP Messages for O-UNI 135 A set of abstract O-UNI messages is defined in [1]. Those abstract 136 messages support the basic functions of the optical UNI. Those 137 functions are, 139 - Lightpath Create: Creates a lightpath with certain attributes between 140 two ends in the optical networks 142 - Lightpath Delete: Deletes an already existing lightpath 144 - Lightpath Modify: Modifies one or more of the attributes of already 145 existing lightpath 147 - Lightpath Status Enquiry: Enquires about the status of an already 148 existing lightpath 150 Each of the above functions is accomplished by a set of O-UNI messages 151 using LDP protocol.The procedures for handling LDP messages across the 152 optical UNI are augmented to add the additional O-UNI functionality. 153 Common across the O-UNI are: 155 Aboul-Magd April 2001 3 156 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 158 - The LDP FEC TLV should be ignored at the O-UNI since it has no 159 significance, and 160 - The use of LDP messages for O-UNI does not change the semantics of 161 the LDP Message ID. 163 5.1. Lightpath Create Action 165 Lightpath Create Action requires two messages, the lightpath Create 166 Request and the Lightpath Create Response. The mapping of the LDP 167 messages to fulfill the lightpath create action is: 169 - Lightpath Create Request: The create request function is achieved by 170 the LDP Label Request Message. The Generalized Label Request TLV 171 defined in [4] is used to convey some lightpath attributes to the 172 network side. 173 - Lightpath Create Response: The create response function is achieved 174 by the use of the LDP Label Mapping Message. The create response 175 function makes use of the Generalized label defined in [4]. The Label 176 Mapping procedures are limited to downstream on demand, ordered control 177 mode with conservative label retention mode. 179 5.2. Lightpath Delete Action 181 Lightpath Delete Action requires two messages, 182 the Lightpath Delete Request and the Lightpath Delete Response. The 183 mapping of the LDP messages to fulfill the function of the lightpath 184 delete action is: 186 - Lightpath Delete Request: The delete request is achieved by the LDP 187 Label Release Request Message. The Label Release Message is sent from 188 the client or the network at any time after the establishment of the 189 lightpath to delete it. 190 - Lightpath Delete Response: The delete Response is achieved by the LDP 191 Label Withdraw Message. The Label Withdraw Message is sent from the 192 client or the network in response to a Label Release Request. 194 5.3. Lightpath Modify Action 196 After a lightpath is setup, some of its attributes, e.g. bandwidth, may 197 need to be changed by the network operator due to new requiremenst for 198 the traffic carried on that lightpath. Lightpath Modify Action does not 199 require the definition of new LDP messages. The modify action follows 200 the procedure described in [5]. 202 Lightpath modification can only be allowed when the lightpath is 203 already established. The procedure described in [5] allows for 204 modification of lightpath attributes without service interruption. Only 205 modifications requested by the owner of a particular lightpath are 206 allowed. 208 Aboul-Magd April 2001 4 209 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 211 The procedure described in [5] for lightpath modification relies on the 212 introduction of the Action Flag (ActFlg) field in the Lightpath Id TLV 213 (see section 6.1.3). Similar to the case in CR-LDP [7], the ActFlg 214 field indicates if the signaled Lightpath Request is an initial 215 lightpath setup or a modification request. 217 5.4. Lightpath Status Action 219 Lightpath Status Actionrequires two messages, Lightpath Status Enquiry 220 and Lightpath Status Response 222 The Lightpath Status Enquiry and Lightpath Status Response functions 223 require the definition of two new LDP messages, The Status Enquiry 224 Message and the Status Response Message. The encoding of the new 225 messages is defined in sections 6.6 and 6.7. 227 5.5. Notification Action 229 The Notification function is similar in scope to that of the CR-LDP 230 Notification Message. Hence the LDP Notification message is used across 231 the O-UNI for this purpose. 233 6. LDP Message Extensions 235 This section gives detailed description of LDP message extensions for 236 the support of O-UNI. 238 6.1. Label Request Message 240 The LDP Label Request Message is as defined in 3.5.8. of [2] with the 241 following modifications (required only if any of O-UNI TLVs is included 242 in the Label Request Message): 244 - The FEC TLV is ignored at the O-UNI 246 - The procedures to handle the Label Request Message are augmented by 247 the procedures for processing of the O-UNI TLVs as defined in this 248 section 250 The encoding for the O-UNI LDP Label Request Message is as follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |0| Label Request (0x0401) | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Message ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | FEC TLV | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Source Id TLV (O-UNI mandatory) | 263 Aboul-Magd April 2001 5 264 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Destination Id TLV (O-UNI mandatory) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Lightpath Id TLV (O-UNI mandatory) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Generalized Label Request TLV (O-UNI mandatory) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Suggested Label TLV (O-UNI optional) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Label Set TLV (O-UNI optional) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Service TLV (O-UNI mandatory) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Optional Parameters | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 6.1.1 Source Id TLV 284 The Source Id TLV is an object that specifies the initiator (the 285 calling party) of the lightpath creation request. The encoding of the 286 Source Id TLV is: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |0|0| Source Id (0x0950) | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Node Address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Port ID | Channel Id | Sub-channel ID| 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 + Source User Group +-+-+-+-+-+-+-+-+ 299 | | Reserved | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Node Address: 303 The Node Address is the IPv4 address associated with the optical 304 network element 306 Port Id: 307 Port Id is a two-octet unsigned integer indicating the port number in 308 an optical network element 310 Channel Id: 311 Channel Id is a single octet unsigned integer indicating a channel 312 with respect to the specified Port Id. 314 Sub-Channel Id: 316 Aboul-Magd April 2001 6 317 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 319 Sub-Channel Id is a single octet unsigned integer indicating a sub- 320 channel with respect to the specified Channel Id. 322 Source User Group: 323 The Source User Group identifies the logical network or group to 324 which the optical client belongs. The Source User group is the 7- 325 octet structure as defined in [6]. 327 6.1.2. Destination Id TLV: 329 The Destination Id TLV has the same structure as the Source Id TLV. The 330 format of the Destination Id TLV is: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |0|0| Destination Id(0x0951) | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Node Address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Port ID | Channel Id | Sub-channel ID| 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 + Source User Group +-+-+-+-+-+-+-+-+ 343 | | Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 6.2.3. Lightpath Id TLV 348 The format of the Lightpath Id is as follows: 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |U|F| lightpath Id (0x0952) | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Reserved | ActFlg| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | optical network element IPv4 address | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Index | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 ActFlag 361 A 4-bit field that explicitly indicates the action that should be 362 taken on an already existing lightpath. A set of indicator code 363 points is proposed as follows 365 0x0 = initial lightpath setup 366 0x1 = modify lightpath 368 Optical Network Element Ipv4 Address 370 Aboul-Magd April 2001 7 371 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 373 The Ipv4 address of the optical network element 375 Index 376 A 4-octet field uniquely identifies a lightpath. 378 6.1.3. Generalized Label Request TLV 380 The Generalized Label TLV format and procedure are as defined in 381 section 3.1 of [4]. It supports communication of characteristics 382 (attributes) required for the lightpath(LSP) being requested. These 383 characteristics include the desired link protection, the lightpath 384 (LSP) encoding, and the lightpath (LSP) payload. 386 6.1.4. Suggested Label TLV 388 The Suggested Label TLV format and procedure are as defined in section 389 3.4. of [4]. 391 6.1.5. Label Set TLV 393 The format and the procedure of the Label Set TLV is as described in 394 section 3.5. of [4]. 396 6.1.6. Service TLV 398 The Service TLV defines the service attributes requested by the network 399 client. The encoding for the Service TLV is as follows: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |U|F| Service (0x0953) | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Contact ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Dir | Trns | Reserved | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Propagation Delay | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Diversity TLV | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Bandwidth | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Contact Id: 418 Contact Id is a 4-octet unsigned integer that uniquely identifies the 419 lightpath owner. It is administratively used for call acceptance, 420 billing, policy decisions, etc. 422 Dir, Directionality 424 Aboul-Magd April 2001 8 425 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 427 Dir is 16-bit field that specifies the directionality of the 428 requested lightpath. The allowed values are: 430 0x0000 = Uni-directional 431 0x0001 = Bi-directional 432 0x000n = Multi-Cast with n destinations 434 Trans, Transparency 435 Transparency is interpreted with respect to the LSP encoding and 436 bandwidth. Trans is a 4-bit field that defines transparency 437 requirements of the lightpath. For SONET/SDH the allowed values are: 439 0x0 = PLR-C 440 0x1 = STE-C 441 0x2 = LTE-C 443 There are no transparency options for PDH, Digital Wrapper, and 444 Ethernet. 446 Propagation Delay 447 Propagation Delay is a 4-octet field. It indicates the maximum 448 acceptable propagation delay in ms. The recommended encoding for this 449 parameter is the 4-octet IEEE floating point number. 451 Diversity TLV 452 Diversity TLV lists all the other lightpaths from which the requested 453 lightpath MUST be diverse. It also specifies the type of diversity. 454 Diversity is only valid within a single routing domain. The encoding 455 of the Diversity TLV is as follows: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |0|0| Diversity TLV (0x0954) | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Lightpath Id TLV 1 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | DivT | Reserved | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Lightpath Id TLV 2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | DivT | Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ~ . . . . . . . ~ 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Lightpath Id TLV n | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | DivT | Reserved | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Aboul-Magd April 2001 9 478 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 480 Lightpath TLV n: 481 is the Lightpath Id of the LSP from which the requested ligthpath 482 must be diverse. 484 DivT, Diversity Type 485 DivT specifies the manner by which the requested lightpath should be 486 diverse. The allowed values are: 488 0x0 = Link diverse 489 0x1 = Node diverse 490 0x2 = Shared Risk Link Group (SRLG) diverse 492 Bandwidth 493 It defines the lightpath bandwidth. Bandwidth is a 4-Octet number in 494 IEEE floating point format (the unit is bytes per second). Some 495 bandwidth values are enumerated in section 3.1.4. of [4] 497 6.1.7. Procedure 499 The O-UNI Label Request Message flows between an optical network client 500 and the edge optical network element. Upon initiating the Label Request 501 Message, the optical client sets the addresses in the optical network 502 for the two ends of the lightpath (Source Id and Destination Id TLVs). 503 For initial setup (ActFlg=0), the lightpath Id is set to all 0s when 504 sent from the client to the network. The lightpath Id is assigned by 505 the optical networks. It is globally unique within the optical network. 506 The Lightpath Id is obtained by combining the IPv4 address associated 507 with the optical network element and an integer index that is locally 508 unique. The Lightpath Id is passed to the called client in the Label 509 Request Message from the network to the optical client. 511 Upon the reception of the O-UNI Label Request Message, the edge optical 512 network element might consult with a policy server to verify that the 513 signaled attributes (including the verification of the Source and the 514 Destination Ids) can be supported. Failure to support one or more of 515 the lightpath attributes triggers the generation of the Notification 516 Message with the appropriate error code. 518 After passing the edge optical network verification process, the edge 519 optical network constructs the generalized MPLS message for lightpath 520 aetup across the optical network. The generalized Label Request Message 521 extracts information from the O-UNI Label Request Message with regard 522 to the Generalized Label Request TLV, the Suggested Label TLV, and the 523 Label Set TLV, whenever applicable. The methods and procedures 524 described in [4] are then followed for end-to-end path setup. 526 Lightpath modification request is achieved by the owner client sending 527 a Label Request Message with ActFlg=1. In this case the lightpath is 528 left unchanged as initially assigned by the network. 530 6.2. Label Mapping Message 532 Aboul-Magd April 2001 10 533 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 535 The Label Mapping Message is as defined in 3.5.7 of [2] with the 536 following modifications: 538 - The Label Mapping Message procedures are limited to downstream 539 on demand ordered control mode. 541 The encoding of the O-UNI Label Mapping Message is as follows: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |0| Label Mapping (0x0400) | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Message ID | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | FEC TLV | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Generalized Label TLV (O-UNI mandatory) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | O-UNI Label Request Message ID TLV | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Lightpath ID TLV (O-UNI mandatory) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Source Id TLV (O-UNI mandatory) | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Destination Id TLV (O-UNI mandatory) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Service TLV (O-UNI optional) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Optional Parameters | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 6.2.1. Generalized Label TLV 568 The Generalized Label TLV format and procedures are as in section 3.2. 569 of [4]. 571 6.2.2. O-UNI Label Request Message ID TLV 573 The O-UNI Label Request Message ID TLV has the same format and 574 procedures as described in [7] 576 6.2.3. Procedure 578 The O-UNI Label Mapping Message flows between an optical network client 579 and the edge optical network element. 581 The reception of the O-UNI Label Mapping Message signifies the 582 successful establishment of a lightpath with the desired attributes. It 583 also signifies the successful modification of one or more of the 584 lightpath attributes. 586 Aboul-Magd April 2001 11 587 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 589 The network transports the assigned Lightpath Id to the calling client 590 in the Label Mapping Message. This Lightpath Id value is used by the 591 client and the network for the exchange of lightpath status 592 information. 594 The O-UNI Label Mapping Message also includes a Generalized Label TLV. 595 Its purpose is to indicate to the client label value, e.g. which 596 wavelength, to be used. 598 The O-UNI Label Mapping Message optionally includes a Service TLV that 599 summarizes the level of service extended from the optical network to 600 its client. The Service TLV must be included for the cases where 601 reserved lightpath attributes, e.g. its bandwidth, are different from 602 those requested by the customer. 604 6.3. The Label Release Message 606 The format of the O-UNI Label Release Message is as follows: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |0| Label Release (0x0403) | Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Message ID | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | FEC TLV | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Generalized Label TLV (O-UNI Optional) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Lightpath ID TLV (O-UNI mandatory) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Optional Parameters | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 6.3.1. Procedure 626 The procedure for the O-UNI Label Release Message is as described in 627 section 3.5.11. of [2]. The O-UNI Label Release Message is sent by 628 either the client or the network to indicate the desire to delete an 629 already established lightpath. The O-UNI Label Release Message carries 630 a mandatory lightpath Id to indicate which lightpath should be 631 terminated. 633 6.4. The Label Withdraw Message 635 The format for the O-UNI Label Withdraw Message is as follows: 637 0 1 2 3 638 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 640 Aboul-Magd April 2001 12 641 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 |0| Label Withdraw (0x0402) | Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Message ID | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | FEC TLV | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Lightpath ID TLV (O-UNI mandatory) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Optional Parameters | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 6.4.1. Procedure 657 The procedure for the Label Withdraw Message follows that defined in 658 section 3.5.10 of [2]. The Label Withdraw Message is sent by the 659 network or the client in response to a Label Release Request. 661 The Label withdraw Message for O-UNI carries a mandatory lightpath Id. 662 The reception of the Label Withdraw Message acts as an indication to 663 the client or the network that the lightpath defined by its Lightpath 664 Id has been terminated. 666 6.5. The Notification Message 668 The Notification Message is as defined in section 3.5.1. of [2] with 669 the following modifications: 671 - The O-UNI Notification Message is sent autonomously from the network 672 side of the O-UNI to the client to indicate the status of the lightpath 673 request. 674 - The O-UNI Notification Message includes a mandatory Lightpath Id TLV 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |0| Notification (0x0001) | Length | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Message ID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Lightpath Id TLV O-UNI (mandatory) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | O-UNI Label Request Message ID TLV | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Status TLV | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Optional Parameters | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 The Status TLV is as defined in section 3.4.6. of [2]. 694 Aboul-Magd April 2001 13 695 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 697 6.5.1. Procedure 699 The O-UNI Notification Message is used by the optical network to signal 700 to its clients failure condition during or after the connection 701 establishment phase. New Status codes relevant to lightpath operation 702 are: 704 0x00001000 = not able to connect to destination user group 705 0x00001001 = invalid destination address 706 0x00001002 = invalid port Id 707 0x00001003 = invalid channel Id 708 0x00001004 = invalid sub-channel Id 709 0x00001005 = bandwidth unavailable 710 0x00001006 = protection mode unavailable 711 0x00001007 = routing directive unavailable 712 0x00001008 = failure to create lightpath 713 0x00001009 = failure to modify lightpath 714 0x0000100A = Failure to delete lightpath 715 0x0000100B = Encoding unavailable 717 If it has been already set, the Notification Messages includes the 718 Lightpath Id TLV. If not set, e.g. for initial set up, the Lightpath Id 719 TLV is set to 0. If the Lightpath Id is not set, the Notification 720 Message MUST includes a O-UNI Label Request Message ID TLV as defined 721 in section 6.2.2. 723 6.6. The Status Enquiry Message 725 The Status Enquiry Message is a new LDP message. The encoding for the 726 Status Enquiry Message is: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |U|F|Status Enquiry (0x0002) | Length | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Message ID | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Lightpath ID TLV | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Optional Parameters | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 6.6.1 Procedure 742 The Status Enquiry Message is sent by the client or the network at any 743 time to solicit a Status Response Message from its peer. The lightpath 744 under consideration is identified by the Lightpath Id TLV. 746 6.7. The Status Response Message 748 Aboul-Magd April 2001 14 749 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 751 The Status Response Message is a new LDP message. The encoding for the 752 Status Response Message is: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |U|F| 0x0003 | Length | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Message ID | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Lightpath ID TLV | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Source Id TLV | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Destination ID TLV | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Service TLV | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Status TLV | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Optional Parameters | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 6.7.1 Procedure 776 The Status Response Message is sent by either the client or the network 777 in response to Status Enquiry Message. The Status TLV carries 778 information that describes the current status of a connection 779 (ligtpath) as defined by the Lightpath Id TLV. The status of the 780 connection is encoded using the LDP Status TLV. 782 The Status Response Message could optionally include lightpath 783 attributes as defined by Source Id, Destination Id, and the level of 784 service. 786 6.7.1.1. Lightpath States 788 Connection States at the client side of the interface are: 790 - Null: no call exists 791 - Call Initiated: this state exist for an outgoing call when the client 792 sends the Label Request Message, but has�t yet received the Label 793 Mapping Message from the network 794 - Call Present: this state exist for an incoming call when the client 795 receives the Label Request Message from the network, but hasn�t yet 796 responded to it 797 - Active: This state exists for an incoming call when the client sends 798 the Label Mapping Message to the network. The state also exist for an 799 outgoing call when the initiating client receives the Label Mapping 800 Message from the network. 802 Aboul-Magd April 2001 15 803 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 805 - Release Request: this state exists when the client has requested the 806 network to clear the end-to-end lightpath, i.e. the client sending the 807 Label Release Message. 808 - Release Indication: this state exists when the client has received an 809 disconnect indication because the network has already disconnected the 810 lightpath, i.e. when the client receives the Label Release Message. 812 Similar connection states exist at the network side of the interface. 813 The Status codes for the lightpath states are: 815 0x0000100C = Null 816 0x0000100D = Call Initiated 817 0x0000100E = Call Present 818 0x0000100F = Active 819 0x00001010 = Release Request 820 0x00001011 = Release Indication 822 7. Security Considerations 824 This security mechanisms defined in [2] shall be used. 826 8. Author's Addresses 828 Osama S. Aboul-Magd Raj Jain 829 Nortel Networks Nayna Networks, Inc. 830 P.O. Box 3511, Station �C� 157 Topaz St. 831 Ottawa, Ontario, Canada Milpitas, CA 95035 832 Canada Phone: 408-956-8000x309 833 Phone: 613-763-5827 Fax: 408-956-8730 834 Email: Osama@nortelnetworks.com Email: Jain@nayna.com 836 LiangYu Jia Bala Rajagopalan 837 ONI Systems Corp. Tellium, Inc. 838 166 Baypoints Parkway 2 Crescent Place 839 San Jose, CA 95134 Ocean Port, NJ 07757 840 Phone: 408-965-2743 Phone: 732-923-4237 841 Fax: 408-965-2660 Fax: 732-923-9804 842 Email: ljia@oni.com Email:braja@tellium.com 844 Robert Ronnison Yangguang Xu 845 Laurel Networks Lucent Technologies 846 2607 Nicholson Rd 1600 Osgood St. 847 Sewickley, PA 15143 N. Anderson, MA 01845 848 Phone: 724-933-7330 Phone:978-960-6105 849 Email:robren@laurelnetworks.com Email:xuyg@lucent.com 851 Zhensheng Zhang 853 Aboul-Magd April 2001 16 854 Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 856 Sorrento Networks 857 9990 Mesa Rim Road 858 San Diego, CA 92121 859 Phone: 858-646-7195 860 Email: zzhang@sorrentonet.com 862 Full Copyright Statement 864 "Copyright (C) The Internet Society (date). All Rights Reserved. This 865 document and translations of it may be copied and furnished to others, 866 and derivative works that comment on or otherwise explain it or assist 867 in its implementation may be prepared, copied, published and 868 distributed, in whole or in part, without restriction of any kind, 869 provided that the above copyright notice and this paragraph are 870 included on all such copies and derivative works. However, this 871 document itself may not be modified in any way, such as by removing the 872 copyright notice or references to the Internet Society or other 873 Internet organizations, except as needed for the purpose of developing 874 Internet standards in which case the procedures for copyrights defined 875 in the Internet Standards process must be followed, or as required to 876 translate it into 878 9. References 880 1 Aboul-Magd, O. et. al., "Signaling Requirements at the IP-Optical 881 Interface (UNI)" draft-ip-optical-uni-signaling-00.txt, work in 882 progress, July 2000. 884 2 Andersson, L., et. al., "LDP Specifications�, draft-ietf-mpls-ldp- 885 08.txt, work in progress, June 2000 887 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 888 Levels", BCP 14, RFC 2119, March 1997 890 4 Ashwood-Smith, P. et. Al., "Generalized MPLS - Signaling Functional 891 Description� draft-ietf-mpls-generalized-signaling-00.txt, Work in 892 Progress, October 2000. 894 5 Ash, J., et, al., "LSP Modification Using CR-LDP", draft-ietf-mpls- 895 crlsp-modify-01.txt, work in progress, Feb. 2000. 897 6 Fox, B. and Gleeson, B., �VPN Identifiers�, IETF RFC-2685, Sept. 898 1999. 900 7 Jamoussi, B. Editor, �Constraint-Based LSP Setup Using LSP�, draft- 901 ietf-mpls-cr-ldp-04.txt, work in progress, July 2000. 903 Aboul-Magd April 2001 17