idnits 2.17.1 draft-saha-rsvp-optical-signaling-00.txt: -(415): 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? == There are 6 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 5 longer pages, the longest (page 4) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 226: '... is reserved. It MUST be set to zero o...' RFC 2119 keyword, line 227: '...transmission and MUST be ignored on re...' 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? '2' on line 208 looks like a reference -- Missing reference section? '3' on line 47 looks like a reference -- Missing reference section? '5' on line 47 looks like a reference -- Missing reference section? '4' on line 381 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Debanjan Saha 2 Expiration Date: Sept., 1, 2000 Bala Rajagopalan 3 Bo Tang 4 Tellium Inc. 6 RSVP Extensions for Signaling Optical Paths 8 draft-saha-rsvp-optical-signaling-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstact 33 This document has two objectives. First, we identify signaling 34 requirements for setting up and maintaining Optical Switched Paths 35 (OSPs) in mesh-connected optical networks. We then propose 36 extensions to RSVP to satisfy some of these requirements within the 37 context of MPLS-based traffic engineering framework. 39 3. Introduction 41 The IETF is currently in the process of defining and standardizing a 42 control architecture for creating and managing switched OSPs. A 43 number of contributions [2,3,5] submitted to IETF, and other 44 standards bodies have already addressed some of the important 45 aspects of this architecture. In this document we have identified 46 several key requirements for signaling OSPs within the framework 47 proposed in [2,3,5] that take into account some of the intricacies 48 of an optical network. In light of these observations, we have 49 proposed extensions to RSVP-TE to satisfy the signaling requirements 50 of OSPs. 52 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 53 4. Optical Network Architecture 55 The optical network model considered in this draft consists of 56 multiple Optical Cross-Connects (OXCs) interconnected by optical 57 links in a general topology referred to as an "optical mesh 58 network". In general, it can be expected that topologically adjacent 59 OXCs in an optical mesh network will be connected via multiple, 60 parallel bi-directional links. Each link can carry one or more 61 optical channels or wavelengths. Each wavelength can be further 62 demultiplexed into multiple Sub-channels. We also assume that one or 63 more control channels exist between neighboring OXCs for signaling 64 purposes. 66 Each OXC is assumed to be capable of switching a wavelength from a 67 given input port to a given output port. This switching function is 68 controlled by appropriately configuring a cross-connect table. In 69 the most general case, the cross-connect table consists of entries 70 of the form , indicating that the 72 Sub-channel k, in wavelength j entering input port i will be 73 switched to Sub-channel p in output wavelength n at output port j. 74 An "optical path" from an ingress port in an OXC to an egress port 75 in a remote OXC is established by setting up suitable cross-connects 76 in the ingress, the egress and a set of intermediate OXCs such that 77 a continuous physical path exists from the ingress to the egress 78 port. 80 Automated establishment of optical paths involves setting up the 81 cross-connect table entries in the appropriate OXCs in a coordinated 82 manner such that the desired physical path is realized. The request 83 to establish an optical path may arise from either a router (or some 84 other device) connected to the OXCs or from a management system. 85 Such a request must identify the ingress and the egress OXC as 86 endpoints of the optical path. In addition, it may also optionally 87 specify the input and output ports, wavelengths, and Sub-channels. 88 The request may also include bandwidth parameters and channel type 89 (e.g., OC-48/OC-192, 10 GE/N), reliability parameters, restoration 90 options, setup and holding priorities for the path etc. On receipt 91 of the request, the ingress OXC computes a suitable route for the 92 requested path, following applicable policies and constraints. Once 93 the route has been computed, the ingress invokes RSVP to set up the 94 path. The purpose of this draft is to identify special requirements 95 for signaling OSPs and propose extensions to RSVP protocol to 96 satisfy those requirements. 98 5. Signaling Requirements 100 5.1 Support for Bi-directional OSPs 102 A OSP can be either unidirectional or bi-directional. However, bi- 103 directional OSPs are far more typical than unidirectional OSPs. 104 Although a bi-directional OSP can be modeled as a pair of 105 unidirectional OSPs that can be setup independently, there are many 106 limitations to this approach. Most importantly, two separately 107 signaled unidirectional OSPs may follow two different paths 109 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 110 altogether. Even if they follow the same path, it is quite likely 111 that they will use two different ports/wavelengths/Sub-channels (on 112 the same OXC) for the forward and the backward directions. Either 113 scenario makes it difficult for the network management system to 114 manage and maintain the OSPs, especially in the event of failures 115 that trigger automatic fault isolation and restoration events such 116 as SONET APS (Automatic Protection Switching). The ability to setup 117 bi-directional OSPs also reduces the signaling complexity and setup 118 time. 120 Since RSVP is designed to setup unidirectional paths, extensions are 121 required for signaling bi-directional paths. The tricky part here is 122 the handling of the potential race condition. Since different nodes 123 may autonomously initiate the signaling for optical paths, it is 124 possible that two path set-up attempts are in progress at the same 125 time. Specifically, while setting up an optical path, an OXC A may 126 select output port i, which is connected to input port j of the 127 "next" OXC B. Concurrently, OXC B may select output port j for 128 setting up a different optical path, where the next downstream OXC 129 is A. If they also happen to choose the same wavelength and Sub- 130 channel (when applicable) this results in a "collision". There are 131 two ways to deal with such collisions. First, collisions may be 132 detected and the involved paths may be torn down and re-established. 133 Or, collisions may be avoided altogether. The latter solution is 134 preferred, if the complexity involved is acceptable. In Section 5 we 135 propose extensions to RSVP-tunnel to handle this race condition 136 which avoids collision. 138 5.2 Support for Protection Paths 140 Another important requirement for lighpaths is protection. We 141 consider two primary protection modes: 143 1. Span protection: In this mode the optical channel between 144 every two adjacent OXCs along the primary path is protected 145 individually. There are different modes of span protection, 146 such as 1+1, M:N etc. 148 2. Path protection: In this mode end-to-end backup paths are 149 provisioned for the primary paths. In path protection backup 150 paths are typically link or link and node disjoint from the 151 primary paths. There could be various levels of sharing among 152 backup paths, such as completely dedicated backup paths (1+1 153 style), backup paths that are shared by multiple primary paths 154 (M:N style), and backup paths that share resources 155 (wavelengths) among themselves. In the first two cases the 156 backup paths span between the same source and the destination 157 pair and can be pre-setup. The backup paths that share 158 resources among themselves can be pre-provisioned but can not 159 be pre-setup. In this scenario the backup paths can span 160 between different source and destination pairs. 162 RSVP-TE has limited support for setting up protection paths. In 163 section 7 we introduce new C-types to signal protection requirements 164 for both span and path protection. We also introduce a new shared 165 reservation style to enable sharing of resources among backup paths. 167 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 168 5.3 Support for Permanent OSPs 170 RSVP relies on soft-state mechanisms to maintain OSPs. If the Path 171 and Resv states corresponding to a OSPs are not refreshed within the 172 configured timeout value, they are timed out and the OSP is deleted. 173 The requirements for OSPs are quite different. Most OSPs are long- 174 lived and should not be torn down unless explicitly requested. Also, 175 the impact of transient partial failures must be minimized in an 176 optical network. Specifically, optical paths that are not directly 177 affected by a failure must not be torn down due to the failure. For 178 example, the control processor in an OXC may fail, affecting 179 signaling and other internodal control communication. Similarly, the 180 control channel between OXCs may be affected temporarily by a 181 failure. These failures may not affect already established OSPs 182 passing through the OXC fabric. These requirements can be summarized 183 as follows: 185 1. During setup OSPs can be configured as permanent OSPs. Permanent 186 OSPs should not be torn down unless explicitly requested. 188 2. The Path and Resv states for permanent OSPs need not be refreshed 189 and should not be timed out. 191 3. We need explicit mechanisms for tearing down permanent OSPs. This 192 requires enhancements to PathTear and ResvTear messages since these 193 messages are not refreshed and are not transported reliably. 195 6. Extensions for Bi-directional OSPs 197 To avoid the potential race condition and collision in label 198 assignment we propose a solution where the OXC with the higher node 199 ID (IP address) is always the owner of the label space between two 200 adjacent OXCs. For the purpose of this discussion we assume that a 201 label consists of three components: (1) the port ID, (2) the 202 wavelength ID, and (3) the sub-channel ID. We also assume that if 203 port i on OXC1 is connected to port j on OXC2, both OXCs have that 204 information available to them via link layer discovery protocol. The 205 wavelength ID and the sub-channel ID are assumed to be the same on 206 both OXCs. 208 We define a new C_type for the label request object defined in [2] 209 as follows: 211 Label Request with OSP 213 Class = 19, C_type = 10 (OSP_Tunnel) 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Reserved | Flags | L3PID | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Port ID | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Wavelength ID | Sub-channel ID | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 226 Reserved: This field is reserved. It MUST be set to zero on 227 transmission and MUST be ignored on receipt. 229 Flags (8 bits): 230 xxxxxxx0 � If the upstream OXC is the slave and no label has been 231 picked. 232 xxxxxxx1 � If the upstream OXC is the master has chosen the label 233 for the OSP. 235 L3PID (16 bits): An identifier of the layer 3 protocol using this 236 path. Standard Ethertype values are used. 238 Port ID (32 bits): Valid only when the LSB of the Flags is set. It 239 is the Port ID of the downstream OXC. 241 Wavelength ID (16 bits): Valid only when the LSB of the Flags is 242 set. It is the wavelength ID within the port ID. 244 Sub-channel ID (16 bits): Valid only when the LSB of the Flags is 245 set. It is the sub-channel ID within the wavelength ID. 247 The basic scheme is as follows. The upstream OXC sends the 248 Label_Request object with of C_type 4 to the downstream OXC. If the 249 upstream OXC is the master (has higher node ID) it picks the label 250 and sets the LSB of Flags to 1. If the upstream OXC is the slave, it 251 sets the LSB of the Flags to 0 and the label is picked by the 252 downstream OXC. Since the master irrespective of the direction of 253 the message flow always picks the label, no collision occurs. 255 We also add a new C_Type (10: OSP_Tunnel) to the Label object. The 256 LABEL object has the following format: 258 LABEL class = 16, C_Type = 10 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 // (Object contents) // 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Port ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Wavelength ID | Sub-channel ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 The contents of a LABEL object are a stack of labels, where each 273 label is encoded in 8 octets as shown above. The top of the stack 274 is in the right 8 octets of the object contents. A LABEL object 275 that contains no labels is illegal. 277 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 278 7. Extensions for Protection Paths 280 To handle this issue we propose a new C_type for the SESSION_ATTRIBUTE 281 object. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | OSP type | Local Prot. | Local Prot. Extension | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Setup Prio | Holding Prio | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 // Optional Subobjects // 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Class-Num: The Class-Num indicates that the object is 207. (TBD) 297 C-Type: The C-Type OSP_Tunnel (10). (TBD) 299 OSP Type (8 bits): 301 01 Permanent Uni-directional Primary Path 302 02 Primary Bi-directional Primary Path 303 03 Permanent Uni-directional Backup Path 304 04 Permanent Bi-directional Backup Path 305 05 Permanent Uni-directional Shared Backup Path 306 06 Permanent Bi-directional Shared Backup Path 307 07 Soft-state Uni-directional Primary Path 308 08 Soft-state Bi-directional Primary Path 309 09 Soft-state Uni-directional Backup Path 310 10 Soft-state Bi-directional Backup Path 312 Local Protection (8 bits): 313 01 1+1 314 02 1:N 316 Local Protection Extension (16 bits): Protection scheme specific 317 information. 319 Setup Priority: The priority of the session with respect to taking 320 resources, in the range of 0 to 7. The value 0 is the highest 321 priority. The Setup Priority is used in deciding whether this 322 session can preempt another session. 324 Holding Priority: The priority of the session with respect to 325 holding resources, in the range of 0 to 7. The value 0 is the 326 highest priority. Holding Priority is used in deciding whether this 327 session can be preempted by another session. 329 Besides the mandatory fields described above, the session attribute 330 object may contain one or more optional subobjects. The subobjects 331 are formatted as TLVs and are defined below. 333 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 334 0 1 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 337 | Type | Length | (Subobject contents) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 340 Type: The Type indicates the type of contents of the subobject. 341 Currently defined values are: 342 0 Reserved 343 1 PRIMARY_OSP subobject 344 2 SHARING_POLICY subobject 346 The PRIMARY_OSP subobject may be included in the SESSION_ATTRIBUTE 347 object while setting up a backup path. This subobject includes 348 information about the primary OSP and may be used for functions such 349 as local admission control, sharing of backup etc. The format and 350 content of this subobject is TBD. 352 SHARING_POLICY subobject may be included in the SESSION_ATTRIBUTE 353 object while signaling to setup shared backup paths. This 354 information can be used to facilitate local sharing decision. The 355 format and content of this subobject is TBD. 357 Note that for the shared backup paths the cross-connects can not be 358 setup during the signaling for the backup path since multiple backup 359 paths may share the same resource and can over-subscribe it. The 360 idea behind shared backups is to make soft reservations and to claim 361 the resource only when it is required. A shared backup path can be 362 converted to a primary path by sending Path refresh messages with 363 OSP Type set to 01 or 02 depending on the type of the backup path. 365 8. Extensions for Permanent OSPs 367 In order to satisfy the requirements for a permanent OSP we need to 368 the followings: 370 1. Add a new session attribute that identifies a OSP as a permanent 371 OSP. If this new attribute is not present, by default an OSP is 372 considered a �soft-state� OSP. For permanent OSPs, the Path State 373 Block (PSB) and the Resv State Block (RSB) are never timed out. The 374 only way to delete a permanent OSP is through explicit signaling, 375 that is via a PathTear or a ResvTear message. 377 2. Since the permanent OSPs are never timed out and the PathTear and 378 ResvTear messages are not refreshed, we need additional mechanisms 379 that can be used to tear down the permanent OSPs in a reliable way. 380 One way to achieve this is to add reliability to PathTear and 381 ResvTear messages as suggested in [4]. The other option is to change 382 the OSP_TYPE of a permanent OSP to a soft-state OSP and then rely on 383 RSVP soft-state mechanisms along with PathTear to tear down the OSP. 385 Internet Draft draft-saha-rsvp-optical-signaling-00.txt 386 9. Summary 388 This draft described some issues that arise in developing signaling 389 procedures for path provisioning and restoration in optical 390 networks. The following signaling requirements were identified: 391 support for support for bi-directional optical path set-up with 392 collision avoidance features, support for protected paths, and 393 support for permanent OSPs. Other requirements may arise as work 394 proceeds in this area. In light of these observations, we propose 395 extensions to RSVP-TE to satisfy these requirements. 397 10. References 399 1. Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-Protocol 400 Lambda Switching: Combining MPLS Traffic Engineering Control With 401 Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt. 403 2. Awduche, et al, "Extensions to RSVP for LSR Tunnels," draft-ietf- 404 mpls-rsvp-lsp-tunnel-04.txt, Work in progress, September 1999 406 3. Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi-protocol 407 Lambda Switching: Issues in Combining MPLS Traffic Engineering 408 Control With Optical Crossconnects", draft-basak-mpls-oxc-issues- 409 00.txt 411 4. Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S., 412 �RSVP Refresh Overhead Reduction Extensions�, draft-ietf-rsvp- 413 refresh-reduct-02.txt. 415 5. Rajagopalan B., Saha D., Tang B., Krishna B., �Signaling Framework 416 for Automated Establishment and Restoration of Paths in Optical Mesh 417 Networks�, dratf-rstb-optical-signaling-framework-00.txt, March 418 2000. 420 11. Author Information 422 Debanjan Saha, Bala Rajagopalan, Bo Tang 423 Tellium Inc. 424 2 Crescent Place 425 P.O Box 901 426 Ocean Port, NJ 07757 427 Email: {dsaha, braja, btang}@tellium.com 429 ********** This draft expires on Sept. 1, 2000 ***********