idnits 2.17.1 draft-ietf-mpls-ldp-optical-uni-01.txt: ** The Abstract section seems to be numbered -(232): 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 4 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 25 longer pages, the longest (page 13) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - A Notification message is sent in response to a connection deletion in the downstream direction, i.e. initiated by a Label Release message. In this case the Status TLV MUST include the status code for "delete_success". The Notification message can be sent in response to a single connection deletion or the deletion of all the connection associated with a source identification point (LDP session, logical link, or TNA address). For single connection deletion the Notification message MUST include the Connection ID of the deleted connection. When used to acknowledge the deletion of a group of connections, the Notification message MUST not contain IDs of any of the connections that were deleted. -- 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.) -- The document date (July 2001) is 8293 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 section? '1' on line 33 looks like a reference -- Missing reference section? '2' on line 67 looks like a reference -- Missing reference section? '3' on line 71 looks like a reference -- Missing reference section? '4' on line 78 looks like a reference -- Missing reference section? '5' on line 89 looks like a reference -- Missing reference section? '6' on line 89 looks like a reference -- Missing reference section? '7' on line 89 looks like a reference -- Missing reference section? '8' on line 1259 looks like a reference -- Missing reference section? '9' on line 532 looks like a reference -- Missing reference section? '10' on line 508 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group O. Aboul-Magd 3 Internet Draft Sandra Ballare 4 Document: draft-ietf-mpls-ldp-optical-uni-01.txt Ewart Tempest 5 Nortel Networks 7 Raj Jain 8 Nayna Networks 10 LiangYu Jia 11 ONI Systems 13 Bala Rajagopalan 14 Tellium Inc. 16 Robert Rennison 17 Laurel Networks 19 Yangguang Xu 20 Lucent Technology 22 Zhensheng Zhang 23 Sorrento Networks 25 July 2001 27 LDP Extensions for Optical User Network Interface (O-UNI) Signaling 29 Status of this Memo 31 This document is an Internet-Draft and is in full conformance with 32 all provisions of Section 10 of RFC2026 [1]. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. Internet-Drafts are draft documents valid for a maximum of 38 six months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet- Drafts 40 as reference material or to cite them other than as "work in 41 progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 1. Abstract 50 In OTNs using overlay model, clients request network services 51 through a user network interface (UNI). This draft describes LDP 52 necessary extensions for signaling support across the optical UNI 54 Aboul-Magd Expires January 2002 1 55 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 57 (O-UNI). LDP extensions are those needed to satisfy the main 58 functions supported at the O-UNI. Those functions are: connection 59 create, connection delete, connection modify, and connection status 60 enquiry. 62 2. Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in RFC-2119 [2]. 68 3. Introduction 70 Several models have been discussed for the support of IP traffic 71 over the transport layer (L1/L0) [3]. Three models are identified 72 and are differentiated based on the amount of routing/topological 73 information exchanged between the optical transport network (OTN) 74 and its clients. Those models are overlay, peer, and augmented 75 models. 77 In an overlay network architecture such as the ITU-T automatic 78 switched OTN (ASTN) [4], there is a clear boundary between the 79 client and the network layers. Routing and topological information 80 does not cross this boundary in the sense that each layer is running 81 its own instant of a routing protocol, e.g. OSPF or entirely 82 different routing protocols. Network clients request network 83 services, e.g. connections, across a well-defined interface. This 84 interface is generally called the optical user network interface (O- 85 UNI). 87 MPLS based protocols have already been proposed for the realization 88 of the optical layer control plane in what is termed as generalized 89 MPLS (GMPLS) [5]. Both CR-LDP [6] and RSVP-TE [7] have been extended 90 for possible use as the control plane signaling protocols. It 91 therefore makes sense to use the same set of protocols for the 92 implementation of the O-UNI. This draft introduces the necessary LDP 93 [8] extensions to support the basic O-UNI functionality. 95 At the O-UNI, four O-UNI actions are provided. Those actions are: 97 - Connection Create: Creates an end-to-end connection across the OTN 98 with specified connection attributes such as bandwidth, diversity, 99 etc. Numerous connection attributes have been articulated in [9] 101 - Connection Delete: Deletes an already existing connection. 103 - Connection Modify: Modifies one or more of the connection 104 attributes of the existing connections. Connection Modify is not 105 supported in this version of the draft. 107 - Status Enquiry: Allows the client to enquire the status of a 108 connection or a group of connections. A connection can be in one 110 Aboul-Magd Expires January 2002 2 111 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 113 of a number of states such as, active, redialing, etc [9]. This 114 operation also allows querying connection information in order to 115 recover connection state. 117 Tightly related to the O-UNI, and any UNI in general, is the need to 118 uniquely identify clients and their points of attachment to the 119 network. An addressing scheme for the OTN has been discussed in [9]. 120 Client identification is based on a transport network address (TNA) 121 that is globally unique and is assigned to the client by the network 122 provider. The scope of the TNA could be on a one-to-one basis with 123 logical links that the network provider provision between an OTN 124 network element (NE) and an OTN client, or it could be a single TNA 125 per OTN (optical transport network) client. In the latter case there 126 is the need to introduce a logical port identifier (LPI) to 127 differentiate between multiple logical links between an OTN client 128 and an OTN NE that share the same TNA address. Similar to the TNA, 129 LPI is assigned to the client by the network provider. Protocol 130 extensions are required to support signaling of the TNA and LPI. 132 O-UNI reference models have been discussed in [9]. The client side 133 of the O-UNI has been denoted as UNI-C, while the term UNI-N has 134 been used to identify the network side of the O-UNI. One or more 135 signaling channels exist between the UNI-C and UNI-N. The UNI 136 control channel MUST support the transport of IP protocols. This 137 capability is necessary since IP based protocols, e.g. LDP, are 138 proposed for O-UNI signaling. 140 4.0 LDP for the O-UNI 142 In extending LDP for implementation at the O-UNI, there have been 143 two main guiding principles. Firstly every effort was made to limit 144 the introduction of new LDP messages. New messages are only 145 introduced whenever the desired functionality could not be supported 146 by existing messages, and have been limited to only those required 147 to support the status enquiry function of the O-UNI. 149 Secondly care has been taken not to violate any of the LDP semantics 150 as defined in [8]. Therefore LDP O-UNI extensions could easily be 151 implemented as a simple add-on to the already existing LDP 152 implementations. 154 The mode of operation of the LDP at the O-UNI is downstream on 155 demand label advertisement with ordered control. 157 4.1 LDP Session Initialization 159 For the O-UNI the LDP session is established between UNI-C and UNI- 160 N. Furthermore the client (UNI-C) MUST play the active role during 161 the LDP session initialization phase. Moreover, if all logical links 162 are in the same O-VPN,: 164 - There will be a single LDP session between an OTN client and an 165 OTN NE, regardless of the number of logical links between them. 167 Aboul-Magd Expires January 2002 3 168 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 170 - In the case of proxy signaling, there will be a single LDP session 171 between a proxy agent and an OTN NE regardless of the number of 172 OTN clients and logical links the proxy agent signals on behalf 173 of. 175 The LDP Hello and Extended Hello SHALL be used for neighbor 176 discovery as specified in [8]. 178 An LDP session starts by UNI-C sending an LDP Initialization message 179 to its neighbor UNI-N over the TCP session. In addition to the 180 parameters described in [8], the Initialization message from the 181 UNI-C to the UNI-N contains all the O-UNI version numbers that are 182 supported by the UNI-C. 184 The UNI-N follows the procedure specified in section 2.5.3 of [8] 185 for the passive LSR. It replies with an Initialization message to 186 propose the parameters it wishes to use. Those parameters MUST 187 include the highest version number from the list advertised by the 188 UNI-C that the UNI-N supports. If the UNI-C and UNI-N have no UNI 189 version in common, the LDP session establishment will fail. 191 The Initialization message also includes a Contract ID TLV. Contract 192 ID is determined by the network provider and identifies the contract 193 agreement between the OTN client and the OTN operator. Its format is 194 determined by the OTN operator. 196 Maintaining the LDP session at the O-UNI MUST follow the procedure 197 explained in section 2.5.6 of [8]. 199 4.2 Connection Create using LDP 201 In LDP, the connection create request is implemented using the Label 202 Request message as defined in [8]. The Label Request message is from 203 the source UNI-C to the source UNI-N. At the other end of the 204 network the Label Request message is sent from the destination UNI-N 205 to destination UNI-C. 207 The requested connection might need to support a number of 208 attributes. Extensions are needed to the Label Request message to 209 support the client signaling of those attributes. 211 OTN connections are usually bi-directional. As in GMPLS, a bi- 212 directional connection is signaled at the O-UNI by the inclusion of 213 the Upstream Label in the Label Request message. Reception of the 214 Label Request message by the destination UNI-C signifies the 215 reservation success, i.e. all the requested connection attributes 216 can be satisfied, of the bi-directional connection. However it 217 doesn�t imply that the connection is available for data transport. 218 Connection is only available when configuration of intermediate 219 cross connects is complete. The Configuration of any intermediate 220 cross connect likely to require some time to complete and, depending 221 on the technology used, this delay may be significant, e.g. in the 222 order of 10's or 100's of ms. 224 Aboul-Magd Expires January 2002 4 225 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 227 The destination UNI-C sends a Label Mapping message in response to 228 the Label Request message, only once it has setup its own switch 229 fabric. If it so desires, the destination UNI-C MAY indicate to the 230 source UNI_C that a reservation confirmation indication is needed. 231 The reservation confirmation indication is implemented using the LDP 232 Notification message with the status code �reservation_confirm�. In 233 general, Uni-directional connections do not require a reservation 234 confirmation indication, and depending on the nature of the 235 application on the destination OTN client that terminates the OTN 236 connection, maybe not even in the case of bi-directional 237 connections. 239 Contention for labels may occur between two bidirectional connection 240 setup requests traveling in opposite directions. This contention 241 occurs when both sides allocate the same resources (labels) at 242 effectively the same time. To resolve contention, the node with the 243 higher node ID will win the contention and it MUST issue a 244 NOTIFICATION message with a "Routing problem/Label allocation 245 failure" indication. Upon receipt of such an error, the node SHOULD 246 try to allocate a different Upstream label (and a different Suggested 247 Label if used) to the bidirectional path. However, if no other 248 resources are available, the node must proceed with standard error 249 handling. 251 Similarly the source UNI-N sends a Label Mapping message to the 252 source UNI-C. At this instant the transport connection is available 253 to the source UNI-C for use provided that its own switch fabric have 254 been setup. Figure 1 shows a timing diagram for a successful 255 establishment of a bi-directional connection. 257 UNI-C UNI-N UNI-N UNI-C 258 | | | | 259 | | | | 260 Label |------>| | | 261 Request | |-------------->| | Label 262 | | |------>| Request 263 | | | | 264 | | | | 265 | | |<------| Label 266 Label | |<--------------| | Mapping 267 Mapping |<------| | | 268 | | | | 269 Reservation |------>| | | Reservation 270 Confirm | | |------>| Confirm 271 | | | | 273 Figure 1: Successful Setup of Bi-Directional Connection 275 The connection create request might fail for a number of reasons, 276 e.g. no bandwidth available, no physical connectivity, SLA 277 violation, connection rejected by far end OTN client. In this case 278 failure of the create request is indicated to the source UNI-C using 279 the LDP Notification message with the status code reflecting the 281 Aboul-Magd Expires January 2002 5 282 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 284 reason for the failure. Figure 2 shows a create request rejection by 285 the netwok. 287 UNI-C UNI-N UNI-N UNI-C 288 | | | | 289 | | | | 290 Label |------>| | | 291 Request | | | | 292 | | | | 293 | | | | 294 Notification |<------| | | 295 | | | | 297 Figure 2: Connection Setup Rejection by the Network 299 Should a client desire to abort the connection create process after 300 sending the Label Request message, an LDP Abort message MUST be sent 301 as defined in section 3.5.9. of [8]. Specifically the Message ID 302 used in the Label Request Message is used in the Abort Message as 303 the temporary local connection identifier. 305 4.3 Connection Deletion Using LDP 307 LDP employs two mechanisms for an LSR (label switched router) to 308 inform its peer to stop using a particular label. The first method 309 is based on the use of Label Withdraw message and it is used to 310 signal to a peer that the peer may not continue to use a specific 311 label mapping that the LSR has previously advertised. The second 312 method is based on the use of Label Release message and it is sent 313 to signal to a peer that the LSR no longer needs a specific label 314 mapping previously requested and/or advertised by the peer. 316 The O-UNI LDP extensions make use of the Label Release and Label 317 Withdraw messages for connection deletion. The choice of which 318 message to use depends on the entity that initiates the deletion. 319 The Label Withdraw message is used for the case where the connection 320 deletion is in the upstream direction. As per the LDP procedure in 321 section 3.5.10 of [8], Label Release message is used in this case to 322 acknowledge the delete request. 324 The Label Release message is used for the cases where connection 325 deletion is in the downstream direction. In this case the delete 326 request is confirmed by the use of LDP Notification message with the 327 status code "delete_success". 329 Figures 3 and 4 show graceful connection deletion requested by the 330 source UNI-C and the destination UNI-C respectively. 332 UNI-C UNI-N UNI-N UNI-C 333 | | | | 334 | | | | 335 Notification |------>| | | 336 | |-------------->| | 338 Aboul-Magd Expires January 2002 6 339 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 341 | | |------>| Notification 342 | | | | 343 | | |<------| Label Withdraw 344 | |<--------------| | 345 Label Withdraw |<------| | | 346 Label release |------>| | | 347 | |-------------->| | 348 | | |------>| Label Release 349 | | | | 351 Figure 3: Graceful Connection Deletion by the Source UNI-C 353 UNI-C UNI-N UNI-N UNI-C 354 | | | | 355 | | |<------| Notification 356 | |<--------------| | 357 Notification |<------| | | 358 Label Release |------>| | | 359 | |-------------->| | 360 | | |------>| Label Release 361 | | |<------| Notification 362 | |<--------------| | 363 Notification |<------| | | 364 | | | | 366 Figure 4: Graceful Connection Deletion by the Destination UNI-C 368 Figure 3 shows that the delete request is preceded by an LDP 369 Notification message with status code �delete_indication�. In all 370 optical networks, loss of light will propagate faster than the 371 delete request. Thus downstream NE will detect loss of light and 372 potentially alarm on it. This alarm could be used to incorrectly 373 trigger restoration and/or protection. To address this issue, a 374 Notification message SHOULD be sent along the connection's route to 375 inform all nodes of the intended deletion. Upon the receipt of this 376 message, each node SHOULD disable its alarm reporting and protection 377 mechanisms on the indicated connection. 379 Figure 5 shows a connection deletion scenario initiated by the 380 network, or a force deletion requested from an OAM entity. In this 381 case both Label Withdraw and Label Release messages are used to 382 initiate the deletion request. 384 UNI-C UNI-N UNI-N UNI-C 385 | | | | 386 | | | | 387 Label |<------| |------>| Label 388 Withdraw | | | | Release 389 | | | | 390 Label |------>| |<------| 392 Aboul-Magd Expires January 2002 7 393 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 395 Release | | | |Notification 396 | | | | 398 Figure 5: Connection Deletion Initiated by the Network 400 4.4 Failure Detection and Recovery Using LDP 402 In optical transport networks, failures in the out-of-fiber 403 signaling communication or optical UNI control plane should not have 404 service impact on the existing optical connections. Under such 405 circumstances, a mechanism MUST exist to detect a signaling 406 communication failure and a recovery procedure SHALL guarantee 407 connection integrity at both UNI-C and UNI-N. 409 The LDP Keep Alive mechanism MUST be used to detect signaling 410 communication failures between a UNI-C and a UNI-N, unless an 411 alternative mechanism is in place to detect such failures more 412 efficiently. During the signaling communication failure all active 413 connections are maintained (the bearer connection is active) and all 414 transient connections (in-progress) are cleared. 416 Upon signaling communication re-establishment (i.e. re-establishment 417 of LDP Keep Alive) a resynchronization period is required in order 418 to synchronize connection state information across the UNI. This 419 synchronization period shall be performed prior to processing new 420 connection requests. 422 The resynchronization period starts by the UNI-C either querying the 423 network (UNI-N) for the (summary or detailed) states of all 424 connections associated with a particular logical link, or otherwise 425 (implicitly or explicitly) deleting them. In the former case, the 426 UNI-N will respond with appropriate status information. The OTN is 427 the master of all oTN connection information. An OTN connection, 428 once created, remains within the OTN until implicitly or explicitly 429 deleted by either of the terminating OTN clients through UNI 430 signaling, or via OTN operator intervention. Specifically the burden 431 is on the OTN client to resynchronize with the OTN. Under no 432 circumstances will the OTN resynchronize with its OTN connection 433 view with that of an OTN client. 435 There are three cases to consider during recovery: 437 a) Both UNI-C and UNI-N have retained connection information during 438 the signaling communication failure. In this case, the recovery 439 consists of synchronizing connection state information. This 440 synchronization process requires UNI-C to send Status Enquiry 441 messages requesting summary connection information. 443 b) The client device lost all connection information in its UNI-C 444 control plane during the signaling communication failure. In this 445 case, the recovery procedure requires the UNI-C to query each 446 connection to its peer UNI-N in order to rebuild the connection 447 state information. This can be performed using the Status Enquiry 449 Aboul-Magd Expires January 2002 8 450 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 452 message(s) requesting detailed connection information based on LDP 453 session, logical link or TNA address. 455 c) The client device lost all connection information in its UNI-C 456 control plane and requires all OTN connections to be deleted on: 458 - A per LDP session basis. 459 - A specific logical link 460 - All logical links that share a specified TNA address 462 In this case, the synchronization is a simple restart process that 463 can be achieved by sending a Label Release message with the 464 corresponding TNA and optional logical port parameters. Figure 6 465 shows the scenario for graceful and forced deletion of all 466 connection in this case (for the purpose of simplicity, the 467 diagram assumes that the OTN connections to be deleted all 468 terminate on the same destination OTN client. In reality, this 469 will almost certainly not be the case). Graceful deletion is 470 indicated by source UNI-N sending a Notification message 471 indicating the intended delete. This Notification message is 472 OPTIONALLY sent in response to the source UNI-C Label Release 473 message. For multiple destinations a separate Notification message 474 SHLL be sent per destination. 476 UNI-C UNI-N UNI-N UNI-C 477 | | | | 478 Label Release |------>| | | 479 | |-------------->| | 480 | | |------>| Notification 481 | | |<------| Label Withdraw 482 | |<--------------| | 483 | | | | 484 | |-------------->| | 485 | | | | 486 | | |------>| Label Release 487 Notification |<------| | | 488 | | | | 490 Figure 6: Deletion of All Connections 492 Resynchronization is deemed to be complete between a given OTN 493 client and OTN NE when each connection for which OTN NE knows about 494 is either queried or deleted by the OTN client. Until such time, no 495 new connections can be established for which the OTN client would be 496 a terminating point. 498 5.0 LDP Extensions for O-UNI 500 This section describes LDP extensions specific for the support of 501 signaling across the optical UNI. 503 5.1 TLV Encoding for Commonly Used Parameters 505 Aboul-Magd Expires January 2002 9 506 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 508 The TLV encoding described in section 3.4 of [8] and in [10] MUST be 509 applicable at the O-UNI. This section describes the O-UNI specific 510 TLV encoding. 512 5.1.1 Src ID TLV 514 A client used the Src ID TLV to indicate its identification 515 parameters. The Src ID TLV MUST contain the source TNA, and 516 OPTIONALLY contain a Logical Link ID. The encoding for the Src ID 517 is: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |U|F| Src TNA Value | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 ~ Src TNA ~ 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Logical Port ID | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Src TNA: 532 Src TNA can be in one of three formats [9]. It can be in either 533 IPv4, IPv6, or NSAP format. Only TNA addresses of the same type 534 can be compared for equivalence. The Src TNA values are: 536 Value Type 537 ------- ------- 538 0x960 IPv4 539 0x961 IPv6 540 0x962 NSAP 542 The NSAP format is structured according to ISO/IEC 8348, 1993 543 (identical to ITU X.213, 1992) 545 Only TNA addresses of the same type SHOULD be compared for 546 equality. 548 Logical Port ID: 549 A 32-bit unsigned number indicating identifying a logical port at 550 the source OTN NE. Logical Port ID is OPTIONAL and, as such, may 551 not be present. 553 5.1.2 Dest ID TLV 555 Dest ID TLV is used to identify the destination end of the 556 connection. The Dest ID TLV encoding is: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |U|F| Dest TNA Value | Length | 563 Aboul-Magd Expires January 2002 10 564 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 ~ Dest TNA ~ 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Logical Port ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Dest TNA: 575 Similar to the Src TLV, the following values MUST be supported 577 Value Type 578 ------- ------- 579 0x963 IPv4 580 0x964 IPv6 581 0x965 NSAP 583 The NSAP format is structured according to ISO/IEC 8348, 1993 584 (identical to ITU X.213, 1992) 586 Only TNA addresses of the same type SHOULD be compared for 587 equality. 589 Logical Port ID: 590 A 32-bit unsigned number indicating identifying a logical port at 591 the destination client device. Logical Port ID is OPTIONAL and, as 592 such, may not be present. 594 5.1.3 Egress Label TLV 596 Egress Label TLV is an OPTIONAL O-UNI defined TLV. Egress Label TLV, 597 when present, indicates the egress label to be used at the 598 destination end of the O-UNI. The encoding for the Egress Label is: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |U|F| Egress Lbl (0x0957) | Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Reserved |L| 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 ~ Label ~ 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 L-bit: 613 If L=0, then the Label value MUST be copied into Label Set TLV in 614 the corresponding outgoing Label Request message from the 615 destination UNI-N to destination UNI-C. If L=1, then the Label 616 value MUST be copied into an Upstream Label TLV in corresponding 617 outgoing Label Request message from the destination UNI-N to the 618 destination UNI-C. As such, the Label Request message originated 620 Aboul-Magd Expires January 2002 11 621 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 623 by the source UNI-C may contain up to two Egress Label TLVs, one 624 with the L-bit set, and the other with the L-bit not set. 626 5.1.4. Connection ID TLV 628 The Connection ID TLV is used to uniquely identify a connection 629 established by the network. The format of the Connection ID TLV is 630 as follows: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |U|F| Connection ID (0x0952) | Length | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Reserved |C| 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | | 640 ~ Connection ID ~ 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 C-bit: 645 The value of the C bit is set by the destination UNI-C whenever a 646 reservation confirmation indication is needed. 648 Connection ID: 649 Connection ID has a variable length in multiple of 32, and is at 650 least 64 bits wide. 652 5.1.5 Diversity TLV 654 Diversity TLV lists all the other connections from which the 655 requested connection MUST be diverse. It also specifies the type of 656 diversity. The encoding of the Diversity TLV is as follows: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |U|F| Diversity TLV (0x0954) | Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Connection ID TLV 1 | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Reserved | DivT | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 ~ . . . . . . . ~ 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Connection ID TLV n | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Reserved | DivT | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Connection ID TLV i: 675 This is the Connection ID of an existing connection from which 676 the requested connection must be diverse. 678 Aboul-Magd Expires January 2002 12 679 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 681 DivT (Diversity Type): 682 DivT specifies the manner by which the requested connection 683 should be diverse. The allowed values are: 685 0x0 = Link diverse 686 0x1 = Node diverse 687 0x2 = Shared Risk Link Group (SRLG) diverse 688 0x3 = Link non-diverse 689 0x4 = Node non-diverse 690 0x5 = SRLG non-diverse 692 5.1.6 Contract ID TLV 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |U|F|Contract ID TLV (0x0956) | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 ~ Contract ID ~ 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Contract ID: 705 This is a variable-length string of characters whose format will 706 be determined by the OTN provider. Contract ID identifies the 707 contracted service level agreement (SLA) that the OTN client has 708 with the OTN operator, and in whose context the connection setup 709 request is made. Contract IDs therefore only have local 710 significance between an OTN client and an OTN NE. 712 5.1.8 O-UNI Service TLV 714 The O-UNI Service TLV describes connection attributes in terms of 715 restoration and routing diversity. The encoding of the O-UNI Service 716 TLV is: 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |U|F| O-UNI Service (0x0953) | Length | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Reserved | Service Level | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Diversity TLV | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Service Level: 729 A Service Level corresponds to carrier-defined characteristics 730 such as time to restore, BER, bumping priority, etc. 732 5.1.9 O-UNI Version Number TLV 734 Aboul-Magd Expires January 2002 13 735 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 737 The O-UNI Version Number TLV is of the form: 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 |U|F|Version Num TLV (0x0955) | Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Major Vesrion Number | Minor Version Number | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Minor version number is set relative to the major version number. 749 5.2 LDP Message Extensions for O-UNI 751 This section describes the necessary extensions for LDP messages for 752 the support of signaling across the O-UNI. This section also 753 includes the definition of the two new messages needed for status 754 enquiry. Those messages are Status Enquiry message and Status 755 Response Message. 757 5.2.1 Hello Message 759 The format and the procedure for the Hello message is as defined in 760 section 3.5.2 in [8]. 762 5.2.2 Initialization Message 764 The encoding for the Initialization message is: 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 |0| Initialization (0x0200) | Message Length | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Message ID | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Common Session Parameters TLV | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | O-UNI Version Number TLV (O-UNI Mandatory) | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 ~ ~ 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | O-UNI Version Number TLV (O-UNI Mandatory) | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Contract ID TLV (O-UNI Mandatory) | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Optional Parameters | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 The initialization message procedure is as described in section 2.5. 787 in [8] and section 4.1 of this draft. 789 Message ID is as defined in section 3.5. in [8]. Common Session 790 Parameter TLV is as defined in section 3.5.3 in [8]. 792 Aboul-Magd Expires January 2002 14 793 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 795 The currently defined values for the O-UNI version Number are: 797 For OIF Demo UNI: 798 Major Version Number = 0x0000, Minor Version Number = 0x0001 800 For OIF UNI 1.0: 801 Major Version Number = 0x0001, Minor Version Number = 0x0000 803 5.2.3 Label Request Message 805 The encoding of the Label Request Message for O-UNI is: 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 |0| Label Request (0x0401) | Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Message ID | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | FEC TLV | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Src ID TLV (UNI mandatory) | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Dest ID TLV TLV (UNI mandatory) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Egress Label TLV (UNI Optional) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Connection ID TLV (UNI mandatory) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Generalized Label Request TLV (UNI mandatory) | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | O-UNI Service TLV (UNI mandatory) | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | SONET/SDH Traffic Parameters TLV (UNI mandatory) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Upstream Label TLV (UNI optional) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Suggested Label TLV (UNI optional) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Label Set TLV (UNI optional) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Optional Parameters | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 The Label Request Message is sent from: 841 - the source UNI-C to source UNI-N to indicate an outgoing 842 connection request; 843 - the destination UNI-N to the destination UNI-C to indicate an 844 incoming connection request. 846 Aboul-Magd Expires January 2002 15 847 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 849 How the Label Request message is propagated through OTN from the 850 source UNI-N to the destination UNI-N is outside the scope of this 851 specification. 853 In the Label Request Message, the initiating UNI-C identifies the 854 two connection termination points (Src and Dest ID TLVs). The UNI-N 855 is expected to assign a Connection ID that is unique within the 856 transport network. The Connection ID is passed to the terminating 857 UNI-C in the Label Request Message by the destination UNI-N. 859 Upon the reception of the Label Request Message, the source UNI-N 860 should verify that the signaled attributes (including the validity 861 of the Source and the Destination IDs) can be supported. Failure to 862 support one or more of the connection attributes triggers the 863 generation of the Notification Message with the appropriate error 864 code. 866 The Label Request message Message ID should be used as a local 867 connection identifier, until such a time when the network-assigned 868 Connection ID is sent back to the source client. As stated in [8], 869 since LSRs use Label Request message IDs as transaction identifiers, 870 an LSR SHOULD NOT reuse the Message ID of a Label Request message 871 until the corresponding transaction completers. Thus the local 872 connection identifier has a very limited lifespan. 874 5.2.4 Label Mapping Message 876 The format of the Label Mapping message for the O-UNI is: 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 |0| Label Mapping (0x0400) | Length | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Message ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | FEC TLV | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Generalized Label TLV (UNI mandatory) | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | UNI Label Request Message ID | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Connection ID TLV (UNI mandatory) | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Optional Parameters | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 The Label Mapping message procedure for the O-UNI is limited to 897 downstream on demand ordered control mode. The UNI Label Mapping 898 Message flows between: 900 - The destination UNI-C to destination UNI-N in response to a Label 901 Request message; 903 Aboul-Magd Expires January 2002 16 904 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 906 - The source UNI-N to the source UNI-C to indicate the successful 907 establishment of a connection requested previously. 909 The network transports the assigned Connection ID to the calling 910 client (source UNI-C) in the Label Mapping Message. 912 A terminating UNI-C that desires to receive a reservation 913 confirmation from the initiating UNI-C MUST set the C-bit in the 914 Connection ID TLV. 916 5.2.5 Label Release Message 918 The encoding for the Label Release message at the O-UNI is: 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |0| Label Release (0x0403) | Length | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Message ID | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | FEC TLV | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Connection ID TLV | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Src ID TLV | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Optional Parameters | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 The LDP Label Release Message is used for connection deletion in the 937 downstream direction, e.g. when the connection termination is 938 initiated by the destination UNI-C (graceful OTN connection 939 deletion) / source UNI-C (non-graceful OTN connection deletion). The 940 O-UNI Label Release Message is sent by: 942 - The source UNI-C to source UNI-N to request the deletion a 943 connection; 945 - The destination UNI-N to a destination UNI-C to indicate the 946 deletion of a connection by the network. 948 For the optical UNI, the receiver of the Label Release Message must 949 respond with a Notification Message with the appropriate status code 950 indicating the success of the delete request. 952 Either the Connection ID TLV or the Src ID TLV MUST be included in 953 the Label Release Message. When the Connection ID TLV is included, 954 it is an indication that the connection identified by this ID is the 955 one to be deleted. The Src ID TLV will only be present if a forced 956 (i.e. non graceful) OTN connection deletion is to be performed. 958 When the Src ID TLV is included, it is an indication to the network 959 that the source UNI-C requires deletion of all the connections 961 Aboul-Magd Expires January 2002 17 962 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 964 associated with the specified logical link. This feature is 965 primarily used for forced deletion of connections in failure 966 recovery. 968 5.2.6 Label Withdraw Message 970 The encoding for the Label Withdraw message at the O-UNI is: 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |0| Label Withdraw (0x0402) | Length | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Message ID | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | FEC TLV | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Connection ID TLV (UNI Mandatory) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Optional Parameters | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 The LDP Label Withdraw message is used for connection deletion in 987 the upstream direction, e.g. when the connection termination is 988 initiated by the destination UNI-C (non-graceful OTN connection 989 deletion) / source UNI-C (graceful OTN connection deletion). The UNI 990 Label Withdraw Message is sent by: 992 - The destination UNI-C to destination UNI-N to request the deletion 993 of a connection 994 - The source UNI-N to the source UNI-C to indicate the deletion of 995 the connection by the network. 997 The procedure for the Label Withdraw Message is defined in section 998 3.5.10 of [8]. The recipient of the Label Withdraw Message MUST 999 respond with a Label Release message as in [8]. The Label Withdraw 1000 message for UNI carries a mandatory Connection ID. 1002 5.2.7 Label Abort Message 1004 The format and the procedure of the Label Abort message are as given 1005 in section 3.5.9 of [8]. 1007 5.2.8 Notification Message 1009 The format of the Notification for the O-UNI is: 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 |0| Notification (0x0001) | Length | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Message ID | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 Aboul-Magd Expires January 2002 18 1020 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1022 | Connection ID TLV | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Label Request Message ID TLV | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Status TLV | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Optional Parameters | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 The UNI Notification Message must be forwarded towards the entity 1032 originating the Label Request, Label Release, Status Enquiry, or 1033 Abort. 1035 The Notification message plays a number of roles within the O-UNI: 1037 - A failed connection setup event is indicated to the source UNI-C 1038 using a Notification message. In this case, the Notification 1039 message is generated in response to a Label Request message before 1040 the source client has been made aware of its associated Connection 1041 ID. Therefore, in this case, the Notification message MUST include 1042 the Label Request Message ID TLV that specifies the Message ID of 1043 the Label Request message of the failed setup (and which 1044 constitutes the source OTN client local connection identifier). 1045 The Status TLV MUST include the status code for the cause of the 1046 failed setup, e.g. "no_bandwidth_available". 1048 - A Notification message is needed to initiate graceful deletion of 1049 a single OTN connection. In this case the Notification message 1050 MUST include the Connection ID of the connection to be deleted. 1051 The "delete_indication" status code must be included. 1053 - A Notification message is sent in response to a connection 1054 deletion in the downstream direction, i.e. initiated by a Label 1055 Release message. In this case the Status TLV MUST include the 1056 status code for "delete_success". The Notification message can be 1057 sent in response to a single connection deletion or the deletion 1058 of all the connection associated with a source identification 1059 point (LDP session, logical link, or TNA address). For single 1060 connection deletion the Notification message MUST include the 1061 Connection ID of the deleted connection. When used to acknowledge 1062 the deletion of a group of connections, the Notification message 1063 MUST not contain IDs of any of the connections that were deleted. 1065 - A Notification message is sent for those cases where the 1066 destination UNI-C requests a reservation confirmation indication 1067 from the source UNI-C. In this case the status TLV MUST include 1068 the "reserv_confirm" status code. 1070 - A Notification message is sent for those cases where the source 1071 UNI-C attempts to abort a connection request after sending the 1072 Label Request Message. The Notification message is sent in 1073 response to an Abort message. In this case the Notification 1074 message MUST include the Label Request Message ID TLV. 1076 Aboul-Magd Expires January 2002 19 1077 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1079 The use of the Notification message for the O-UNI includes those 1080 procedures that are specified in [8]. 1082 5.2.9 Status Enquiry Message 1084 The Status Enquiry is a new LDP message that is defined specifically 1085 for LDP applications for O-UNI signaling. The encoding for the 1086 Status Enquiry Message is: 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 |U|F| Status Enquiry (0x0420) | Length | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Message ID | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Reserved |S| 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Src ID TLV 1 | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 ~ ~ 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Src ID TLV m | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Connection ID TLV 1 | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | | 1108 ~ ~ 1109 | | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Connection ID TLV n | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Optional Parameters | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 The Status Enquiry message allows a client to enquire about the 1117 status of a connection or group of connections for which the client 1118 is an end point. 1120 When a Src ID TLV is present in the Status Enquiry message, the 1121 client is in effect requesting the status of all connections 1122 associated with the specified logical link. 1124 When a Connection ID TLV is present in the Status Enquiry message, 1125 the client is requesting the status of this particular connection. 1127 Status Enquiry can be generated by the client at any time. The 1128 Status Enquiry message is used to enquire about status of already 1129 existing connections. 1131 S-bit: 1133 Aboul-Magd Expires January 2002 20 1134 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1136 Whenever the S bit is set, S=1, it indicates that the Status 1137 Enquiry message is for summary information. In that case the 1138 Status Response message contains summary information (Connection 1139 ID and connection Status) of the specified connections. Otherwise, 1140 S=0, detailed information is requested. 1142 5.2.10 Status Response Message 1144 The Status Response message is a new LDP message that is defined 1145 specifically for LDP applications for O-UNI. The encoding for the 1146 Status Response message is: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 |U|F| Status Response (0x0421) | Length | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Message ID | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Connection ID TLV 1 | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Src ID TLV | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Dest ID TLV TLV | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Egress Label TLV | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | O-UNI Service TLV | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | SONET/SDH Traffic Parameters TLV | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Label TLV | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Upstream Label TLV | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Status TLV | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | | 1174 ~ ~ 1175 | | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Connection ID TLV n | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Src ID TLV | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Dest ID TLV TLV | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Egress Label TLV | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | O-UNI Service TLV | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | SONET/SDH Traffic Parameters TLV | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Label TLV | 1191 Aboul-Magd Expires January 2002 21 1192 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Upstream Label TLV | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Status TLV | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Optional Parameters | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 The Status Response message is generated in response to a Status 1203 Enquiry message. The Status Response message contains information 1204 regarding the status of those connections (implicitly or explicitly) 1205 specified in the Status Enquiry message to which it is a response. 1206 The amount information included in the Status Response message 1207 depends on the whether the Status Enquiry is for summary or detailed 1208 information. 1210 6.0 Status Code Summary 1212 The following are the status codes defined for this version of LDP 1213 O-UNI protocol. 1215 0x000000xx = destination_not_reachable 1216 0x000000xx = invalid_destination_TNA 1217 0x000000xx = bandwidth_unavailable 1218 0x000000xx = protection_mode_unavailable 1219 0x000000xx = routing_directive_unavailable 1220 0x000000xx = Failure_to_delete_connection 1221 0x000000xx = Encoding_unavailable 1222 0x000000xx = bad_egress_label 1223 0x000000xx = delete_indication 1224 0x000000xx = delete_success 1225 0x000000xx = reserv_confirm 1226 0x000000xx = abort_complete 1228 0x000000xx = Connection active 1229 0x000000xx = Connection doesn't exist 1230 0x000000xx = Connection unavailable 1231 0x000000xx = Connection dropped by far end 1232 0x000000xx = Connection Pending 1234 7. IANA Consideration 1236 This draft requires the use of a number of new messages, TLVs, and 1237 status codes from the number spaces within the LDP protocol. 1239 The two new messages (sections 5.2.9 and 5.2.10) and the eight new 1240 TLVs (sections 5.1.1 to 5.1.8) should be considered as part of LDP 1241 base protocol and be assigned message and TLV types accordingly as 1242 outlined in [8]. All the values given in this draft should be 1243 interpreted as advisory. There does not exist a preference to what 1244 values should be used. 1246 Aboul-Magd Expires January 2002 22 1247 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1249 The authors' current understanding is that MPLS status codes are not 1250 sub-divided into specific ranges for different types of error. Hence, 1251 the numeric status code values assigned for this draft should simply 1252 be the next available values at the time of writing and may be 1253 substituted for other numeric values. See section "Status Codes" for 1254 details of the status codes defined in this draft. 1256 8. Security Considerations 1258 This draft doesn't introduce any new security issues other than 1259 those in [8]. 1261 9. References 1263 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1264 9, RFC 2026, October 1996. 1266 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1267 Levels", BCP 14, RFC 2119, March 1997 1269 3 B. Rajagopalan, "IP over Optical Networks: A Framework", draft- 1270 ietf-ipo-framework-oo.txt, work in progress, July 2001. 1272 4 Mayer, M. Ed., "Requirements for Automatic Switched Transport 1273 Networks (ASTN)", ITU G.807/Y.1301, V1.0, May 2001. 1275 5 Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling 1276 Functional Description", draft-ietf-mpls-generalized-signaling- 1277 04.txt, work in progress, May. 2001 1279 6 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP 1280 Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in 1281 progress, May 2001 1283 7 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE 1284 Extensions", draft-ietf-mpls-generalized-rsvp-te-03.txt, work in 1285 progress, May 2000. 1287 8 Anderson, L., et. al., "LDP Specification", RFC 3036, January 1288 2001. 1290 9 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0 1291 Signaling Specifications", OIF Contribution, OIF2000.125.5, June 1292 2001 1294 10 Jamoussi, B., "Constraint-Based LSP Setup using LDP", draft-ietf- 1295 mpls-cr-ldp-04.txt, work in progress, July 2000. 1297 Aboul-Magd Expires January 2002 23 1298 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1300 10. Author's Addresses 1302 Osama S. Aboul-Magd 1303 Nortel Networks 1304 P.O. Box 3511, Station �C� 1305 Ottawa, Ont, K1Y-4H7 1306 Tel : 613-763-5827 1307 e.mail :osama@nortelnetworks.com 1309 Sandra Ballarte 1310 Nortel Networks 1311 P.O. Box 3511, Station C 1312 Ottawa, Ontario, Canada 1313 K1Y-4H7 1314 Phone: 613-763-9510 1315 Email: ballarte@nortelnetworks.com 1317 Ewart Tempest 1318 Nortel Networks 1319 P.O. Box 3511, Station C 1320 Ottawa, Ontario, Canada 1321 K1Y-4H7 1322 Phone: 613-768-0610 1323 Email: ewart@nortelnetworks.com 1325 Raj Jain 1326 Nayna Networks, Inc. 1327 157 Topaz St. 1328 Milpitas, CA 95035 1329 Phone: 408-956-8000x309 1330 Fax: 408-956-8730 1331 Email:raj@nayna.com 1333 Liangyu Jia 1334 ONI Systems Corp. 1335 166 Baypoints Parkway 1336 San Jose, CA 95134 1337 Tel: 408-965-2743 1338 Fax: 408-965-2660 1339 e.mail:ljia@oni.com 1341 Bala Rajagopalan 1342 Tellium, Inc. 1343 2 Crescent Place 1344 Ocean Port, NJ 07757 1345 Email :braja@tellium.com 1347 Robert Rennison 1348 Laurel Networks 1349 2607 Nicholson Road 1350 Sewickley, PA 15143, USA 1351 Tel: +1 724-933-7330 1352 Email:robren@laurelnetworks.com 1354 Aboul-Magd Expires January 2002 24 1355 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1357 Yangguang Xu 1358 Lucent Technologies Inc. 1359 21-2A41 1360 1600 Osgood St. 1361 N. Anderson, MA 01845 1362 Tel : 978-960-6105 1363 e.mail :xuyg@Lucent.com 1365 Zhensheng Zhang 1366 Sorrento Networks 1367 9990 Mesa Rim Road 1368 San Diego, CA 92121 1369 Tel: 858-646-7195 1370 e.mail:zzhang@sorrentonet.com 1372 Aboul-Magd Expires January 2002 25 1373 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001 1375 Full Copyright Statement 1377 "Copyright (C) The Internet Society (date). All Rights Reserved. 1378 This document and translations of it may be copied and furnished to 1379 others, and derivative works that comment on or otherwise explain it 1380 or assist in its implmentation may be prepared, copied, published 1381 and distributed, in whole or in part, without restriction of any 1382 kind, provided that the above copyright notice and this paragraph 1383 are included on all such copies and derivative works. However, this 1384 document itself may not be modified in any way, such as by removing 1385 the copyright notice or references to the Internet Society or other 1386 Internet organizations, except as needed for the purpose of 1387 developing Internet standards in which case the procedures for 1388 copyrights defined in the Internet Standards process must be 1389 followed, or as required to translate it into 1391 Aboul-Magd Expires January 2002 26