idnits 2.17.1 draft-bala-restoration-signaling-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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. ** 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 278: '... MAY be pre-configured to be ph...' RFC 2119 keyword, line 437: '... MUST be the same as the set receive...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 333 has weird spacing: '...fecting both...' == Line 637 has weird spacing: '...eceived failu...' -- 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 1031 looks like a reference -- Missing reference section? '2' on line 300 looks like a reference -- Missing reference section? '3' on line 1041 looks like a reference -- Missing reference section? '5' on line 1055 looks like a reference -- Missing reference section? '6' on line 1041 looks like a reference -- Missing reference section? '7' on line 1041 looks like a reference -- Missing reference section? '8' on line 1041 looks like a reference -- Missing reference section? '9' on line 1052 looks like a reference -- Missing reference section? '10' on line 1052 looks like a reference -- Missing reference section? '4' on line 1045 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Bala Rajagopalan 3 Internet Draft Debanjan Saha 4 draft-bala-restoration-signaling-01.txt Tellium, Inc. 5 Expires on: 2/20/2002 Greg Bernstein 6 Ciena Corp. 7 Vishal Sharma 8 Metanoia, Inc 10 Signaling for Fast Restoration in Optical Mesh Networks 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 Restoration of switched connections under tight time constraints is 36 a challenging problem in optical mesh networks. This draft describes 37 different protection modes for connections under both local and end- 38 to-end restoration scenarios, and defines lightweight protocol 39 mechanisms (over IP) for restoration-related signaling. 41 2. Introduction 43 Restoration of switched connections under tight time constraints is 44 a challenging problem in optical mesh networks. Such a network 45 consists of optical cross-connects (OXCs) connected in a general 46 topology [1]. Restoration typically involves the activation of an 47 alternate path for a connection when a failure is encountered in the 48 primary path. A path for a connection (primary or alternate) is 49 characterized by an ingress port, an egress port, and a set of 50 intermediate OXCs and links through which the connection is routed. 51 The ingress and egress port remain the same for primary and 52 alternate paths, but the rest of the paths are typically resource- 53 disjoint (e.g., node or link disjoint). 55 A bi-directional link between neighboring OXCs is usually realized 56 as a pair of unidirectional links. The end-to-end path for a bi- 57 directional connection therefore consists of a series of bi- 58 directional links between the source and destination OXCs, 59 traversing intermediate OXCs. 61 The manner in which restoration is accomplished depends on the type 62 of protection afforded to the connection. In this regard, protection 63 can be "local span" or "end-to-end". Local span protection refers to 64 the protection of the connection segment between two neighboring 65 switches. End-to-end protection refers to the protection of the 66 entire connection from the ingress to the egress port. A connection 67 may be subject to both local span protection (for each of its 68 segments) and end-to-end protection (when local protection does not 69 succeed). Under local span and end-to-end protection schemes, it may 70 be required that when a failure affects any one direction of the 71 connection, both directions of the connection are switched to a new 72 link or path, respectively. In the following, therefore, any 73 reference to a "link" indicates a bi-directional link (realized as a 74 pair of uni-directional links). 76 Considering local-span protection, suppose a connection segment is 77 routed over link i between two OXCs A and B. The following 78 protection modes may be used: 80 1+1 (unidirectional): A dedicated alternate link j is pre- 81 assigned to protect link i. Connection traffic is 82 simultaneously sent on both links and received from one of the 83 functioning link, i or j. 85 1+1 (bi-directional): A dedicated alternate link j is pre- 86 assigned to protect link i. Connection traffic is 87 simultaneously sent on both links and under normal conditions, 88 the traffic from link i is received by OXCs A and B (in the 89 appropriate directions). A failure affecting link i results in 90 both A and B switching to the traffic on link j in the 91 respective directions. 93 1:M: A dedicated link j between A and B is pre-assigned to 94 protect a set of M links (which includes i). A failure 95 affecting any link in this set results in the corresponding 96 traffic being restored to link j. Clearly, if more than one 97 link in the set of M links are concurrently affected by 98 failures, the traffic on only one of them may be restored over 99 link j. 101 M:N (with pre-configured protection groups): A protection group 102 of M+N links consists of a set of M links protected by a set of 103 N links, with N < M. (Link i must be one of the M links in a 104 protection group, and link j is one of the N links). A failure 105 in any of the M links results in traffic being switched to one 106 of the (available) N links. The number of protection groups 107 between A and B, the value of M and N, as well as the specific 108 links in each protection group is pre-configured. Since N < M, 109 it is possible that not all failed links in the set of M links 110 may be protected from the same failure event. 112 M:N (pooled protection links): Under this mode, a total of N 113 links are assigned to protect a total of M other links betwen A 114 and B, where M+N is the total number of links between A and B. 115 (Link i must be one of the set of M links, and link j is one of 116 the set of N links). The value of M and N is pre-configured, 117 and the specific links in the set of N protection links may 118 also be pre-configured. As before, since N < M, it is possible 119 that not all failed links in the set of M links may be 120 protected from the same failure event. 122 With SONET links, 1+1, 1:M and M:N with pre-configured protection 123 groups are typically realized using SONET protocols. In this draft, 124 we therefore focus on M:N protection with pooled protection links. 125 This sort of protection requires a higher layer signaling protocol, 126 as defined in this draft later. 128 Considering end-to-end protection, suppose a connection's primary 129 (bi-directional) path is from an ingress port in OXC A to an egress 130 port in OXC B over a set of intermediate OXCs. The following 131 protection modes may be used: 133 1+1 (unidirectional): A dedicated, resource-disjoint alternate path 134 is pre-established to protect the connection. Connection traffic is 135 simultaneously sent on both paths and received from one of the 136 functional paths by the end OXCs, A and B. 138 1+1 (bi-directional): A dedicated, resource-disjoint alternate path 139 is pre-established to protect the connection. Connection traffic is 140 simultaneously sent on both paths and under normal conditions, the 141 traffic from the primary path is received by OXCs A and B (in the 142 appropriate directions). A failure affecting the primary path 143 results in both A and B switching to the traffic on the back-up path 144 in the respective directions 146 Shared: An alternate path is pre-assigned to protect the connection, 147 but the links along the alternate path are shared among multiple 148 connections being protected. In this case, the links are allocated 149 in real-time for one of the protected connections whose primary path 150 is affected by a failure. If more than one such connection is 151 concurrently affected by a failure, only one of them will be allowed 152 to use a shared link. 154 New protocols are required to realize both 1+1 (bi-directional) and 155 shared end-to-end protection in optical mesh networks. Specifically, 156 1+1 (bi-directional) protection requires coordination between the 157 end OXCs to switch to the protection path, and shared protection 158 additionally involves the intermediate OXCs in the protection path. 160 The aim of this draft is to define the signaling protocols for both 161 M:N pooled local span protection and the two end-to-end protection 162 modes, 1+1 (bi-directional) and shared. The main requirements on 163 these protocols are simplicity and speed. The latency requirement on 164 switching to protection paths is typically specified in tens to 165 hundreds of milliseconds, the performance depending on the number of 166 hops involved. It is clear that a protocol level specification 167 itself cannot guarantee these performance numbers, since a lot 168 depends on the system architecture of the OXCs that implement the 169 protocols. Indeed, this is the reason why these protocols are 170 presently being implemented in a proprietary manner. It is, however, 171 a reasonable goal to aim for a lightweight protocol mechanism that 172 has a good chance of achieving the target performance. This is 173 precisely the objective of this draft. Given the fact that IP- 174 centric (GMPLS) protocols have been widely accepted for provisioning 175 of primary and back-up paths, it is natural to consider standard, 176 IP-based restoration protocols to move away from proprietary 177 restoration solutions. 179 In the next section, the basic signaling mechanism proposed for fast 180 restoration is outlined. Sections 4 and 5 describe local span and 181 end-to-end protection protocols in detail. Section 6 presents some 182 discussion items and Section 7 presents the conclusions. 184 3. Signaling Mechanism 186 3.1 Description 188 As described in the next two sections, the signaling protocols for 189 local and end-to-end protection rely on a small set of short 190 messages. A question that arises is whether an existing protocol 191 framework could be used for supporting such messages. For instance, 192 it is conceivable that RSVP-TE or CR-LDP protocols may be extended 193 to support restoration signaling in the same way they are used for 194 provisioning. In our view, restoration signaling must be given the 195 highest priority and presently, there is no means to give relative 196 priorities to different RSVP or CR-LDP messages (if used for both 197 provisioning and restoration). Furthermore, our desire is to specify 198 a lightweight protocol not encumbered by any of the RSVP or LDP 199 semantics. Indeed, even if these protocols are extended for 200 restoration signaling, they will in essence implement a logically 201 distinct protocol framework for restoration as compared to signaling 202 for provisioning. In this sense, it seems best to start with a new 203 protocol dedicated for restoration signaling. This is indeed the 204 proposal made in this draft. 206 To main aspects of the proposed signaling mechanism are as follows: 208 o The signaling mechanism consists of new protocol running 209 directly on top of IP 211 o The signaling mechanism supports a small set of messages, each 212 of which is succinct, transported in a single short IP packet 214 o The signaling mechanism supports reliable delivery via a simple 215 retransmission mechanism 217 o Signaling messages are sent over the IP control channel between 218 neighboring OXCs. This control channel can be in-band or out- 219 of-band. 221 As per this proposal, an implicit peering relationship exists 222 between protocol instances in two OXCs when the OXCs are topological 223 neighbors in the data plane. Such a pair of OXCs must have one or 224 more control channels between them, in-band or out-of-band. The 225 number of protocol instances running in an OXC, and how the 226 signaling pertaining to different connections are distributed within 227 an OXC would depend on the system architecture. These details are 228 beyond the scope of this draft. 230 The general format of signaling messages under this proposal is 231 given below: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 // IP Header (20 Octets) // 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | Length | Checksum | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 // Data (Variable) // 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 The source and destination address in the IP header are set to the 244 sending OXC and the (neighboring) receiving OXC. The protocol ID in 245 the IP header is set to the (yet unassigned) new value corresponding 246 to the restoration protocol. 248 The restoration message types and data are as defined in the 249 following sections. The 16-bit checksum field covers the entire 250 restoration message, starting from the type field. The Length field 251 indicates the number of 4-octet words in the message, starting with 252 the Type field. 254 3.2 Applicability 256 The proposed signaling protocols for local span and end-to-end 257 protection are intended to be applicable in both networks of O-E-O- 258 type OXCs or all-optical OXCs. Because of the emphasis on bi- 259 directional connections, the 1+1 protection procedures as described 260 in this draft may not be relevant in general MPLS networks. Because 261 of the need to configure intermediate OXCs in real-time for end-to- 262 end shared protection, this procedure is also not applicable in 263 general MPLS networks. 265 4. Local Span Protection 267 Local span protection is described with respect to two neighboring 268 OXCs A and B. The scenario considered for local span protection is 269 as follows: 271 o At any point in time, there are two sets of links between A and 272 B, i.e., a "working" set of M (bi-directional) links carrying 273 traffic subject to protection and a "free" set of N (bi- 274 directional) links. A free link may have no traffic on it, or 275 it may be carrying preemptable traffic. There is no apriori 276 relationship between the two sets of links, but the value of M 277 and N are pre-configured. The specific links in the free set 278 MAY be pre-configured to be physically diverse to avoid the 279 possibility that failure events affect a large proportion of 280 free links (along with working links). 282 o When a link in the "working" set is affected by a failure, the 283 traffic on it is diverted to a link in the "free" set, if such 284 a link is available. Note that such traffic might consist of 285 more than one connection, for example, an OC-192 link carrying 286 four OC-48 connections. 288 o More than one link in the "working" set may be affected by the 289 same failure event. In this case, there may not be an adequate 290 number of "free" links to accommodate all of the affected 291 traffic carried by failed "working" links. The set of affected 292 "working" links that are actually restored over available 293 "free" links is then subject to policies (e.g., based on 294 relative priority of working traffic). These policies are not 295 specified in this draft. 297 o Each OXC is assumed to have the mapping of its local link (or 298 port) ID to the corresponding ID at the neighbor. This mapping 299 could be configured, or obtained automatically using a neighbor 300 discovery procedure (e.g., LMP [2]). 302 o When traffic must be diverted from a failed link in the 303 "working" set to a "free" link, the decision as to which "free" 304 link is chosen is always made by one of the OXCs, A or B. As 305 per this draft, the OXC with the numerically larger IP address 306 is considered the "master" and it is required to both apply any 307 policies and select specific "free" links to divert working 308 traffic. The other OXC is considered the "slave". The 309 determination of the master and the slave may be based on 310 configured information, or the result of running a neighbor 311 discovery procedure. 313 o Failure events themselves are assumed to be detected by lower 314 layer mechanisms (e.g., SONET). Since the bi-directional links 315 are formed by a pair of unidirectional links, a failure in the 316 link from A to B is typically detected by B and a failure in 317 the opposite direction is detected by A. It is possible that a 318 failure simultaneously affects both directions of the bi- 319 directional link. In this case, A and B will concurrently 320 detect failures, in the B-to-A direction and in the A-to-B 321 direction, respectively. 323 The basic steps in local span protection are as follows: 325 1. If the master detects a failure of a "working" link, it 326 autonomously invokes a process to allocate a "free" link to the 327 affected traffic. 329 2. If the slave detects a failure of a "working" link, it must 330 inform the master of the failure. The master then invokes the 331 same procedure as above to allocate a "free" link. (It is 332 possible that the master has itself detected the same failure, 333 for example, a failure simultaneously affecting both 334 directions of a link). 336 3. Once the master has determined the identity of the "free" link, 337 it indicates this to the slave and requests the switchover of 338 the traffic. Prior to this, if the "free" link is carrying 339 preemptable traffic, the master stops using the link for this 340 traffic (i.e., the traffic is dropped by the master and not 341 forwarded into or out of the "free" link). 343 4. The slave sends an acknowledgement to the master. Prior to 344 this, if the selected "free" link is carrying preemtable 345 traffic, the slave stops using the link for this traffic (i.e., 346 the traffic is dropped by the slave and not forwarded into or 347 out of the "free" link). It then starts sending the (failed) 348 "working" link traffic on the selected "free" link. 350 5. When the master receives the acknowledgement, it starts sending 351 and receiving the (failed) working link traffic over the new 352 link. 354 From the description above, it is clear that local span restoration 355 requires three messages for each working link being switched: a 356 failure indication message, a switchover request message and a 357 switchover response message. The following identifier is also 358 needed: 360 4.1 Identifiers 362 Link ID: A 32-bit identifier that uniquely identifies a bi- 363 directional link at the sending and the receiving OXC. The link ID, 364 for instance, could be the port ID at the receiving OXC. 366 The messages are as follows. 368 4.2 Failure Indication Message 370 This message is sent from the slave to the master to indicate the 371 failure of one or more working links. (This message may not be 372 necessary when the underlying link technology itself provides for 373 such a notification) 375 The format of this message is as follows: 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type=0x01 | Length | Checksum | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | ID of failed link | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 // ID of failed link // 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 The number of links included in the message would depend on the 386 number of failures detected within a window of time by the sending 387 OXC. An OXC may choose to send separate failure indication messages 388 in the interest of completing the restoration for a given link 389 within an implementation-dependent time constraint. 391 The ID of the failed link is the identification used at the slave 392 OXC. The master must convert this to the corresponding ID at its 393 side. 395 This message is transmitted periodically by the slave, as controlled 396 by the configurable timer, Retransmission Timer. The default value 397 of this timer is 30ms. The slave stops transmitting this message 398 under the following conditions: 400 o A corresponding Switchover Request message is received; 402 o The Failure Indication Timer expires (the action in the latter 403 case is undefined in this draft. For instance, the sending OXC 404 may notify a management system. The default value for this 405 timer is 500 ms); or 407 o The connection is de-provisioned. 409 4.3 Switchover Request Message 411 This message is sent from the master to the slave to indicate 412 whether the traffic on the failed working link can be switched to a 413 free link, and if so, the ID of the free link. 415 The format of this message is as follows: 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type=0x02 | Length | Checksum | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Message ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | ID of failed link | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | ID of free link | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 // ID of failed link // 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 // ID of free link // 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The link IDs are based on the identification used at the master. The 432 slave must convert them to the corresponding local IDs. The message 433 ID uniquely identifies the message at the master. 435 If the message is generated in response to a Failure Indication 436 message from the slave then the set of failed links in the message 437 MUST be the same as the set received in the Failure Indication 438 message. If the ID of the free link is the same as the ID of the 439 failed link then it is implicit that the traffic on the failed link 440 cannot be switched to a free link. 442 This message is transmitted periodically by the master, as 443 controlled by the configurable parameter, Retransmission Timer. The 444 default value of this parameter is 30ms. Each retransmitted message 445 has the same content, including the Message ID. The master stops 446 transmitting this message under the following circumstances: 448 o The Switchover Timer expires (the action in the latter case is 449 undefined in this draft. For instance, the master may notify a 450 management system. The default value for this timer is 300 ms); 451 or 453 o The connection is de-provisioned 455 o The corresponding Switchover Response is received. 457 A failure event may result in the master sending more than one 458 Switchover Request message to the same slave OXC. In this case, each 459 of these messages will have different Message IDs and indicate 460 different failed links. The retransmission of each is controlled by 461 a different instance of the Retransmission Timer. 463 4.4 Switchover Response Message 465 This message is sent from the slave to the master to indicate the 466 receipt of the Switchover Request message. 468 The format of this message is as follows: 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type=0x03 | Length | Checksum | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Received Message ID | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 // ID of failed link // 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 The Received Message ID field is filled with the Message ID received 479 in the corresponding Switchover Request message. The failed link ID 480 field, if present, indicates that the slave cannot switch over to 481 the corresponding free link for some reason. This identification is 482 based on the IDs used at the slave. The action to be taken by the 483 master when there are one or more failed link IDs in the Switchover 484 Response message is undefined (for example, the master may abort the 485 switchover of the traffic on the failed working link, and perhaps 486 trigger end-to-end protection). 488 The slave responds with the appropriate Switchover Response each 489 time it receives a Switchover Request Message (including 490 retransmitted Switchover Request messages). Of course, the 491 switchover action itself must be performed only once by the slave 492 for a given failed link. 494 5. End-to-End Protection 496 One of the significant differences between end-to-end protection and 497 local span protection (as considered in this draft) is that the 498 latter is on a per-link basis while the former is on a per- 499 connection basis. In other words, span protection switches over the 500 entire traffic on a link which may consist of multiple connections. 501 End-to-end protection, on the other hand, switches over individual 502 connections. In this case, there is a "working" connection path and 503 a "protection" path. 505 Another difference between end-to-end and local protection is that 506 signaling messages may have to be transmitted multiple hops to 507 effect restoration. The signaling messages are transmitted along the 508 connection path, working or protection, where it is assumed that 509 there is a control channel between each pair of intermediate OXCs. 511 There are two cases to be considered: signaling for bi-directional 512 1+1 protection and for shared protection. The description below is 513 in the context of an end-to-end connection between a source OXC A 514 and a destination OXC B. The source for such a connection is also 515 considered to be the "owner" of the connection. The owner is the 516 node which initiated the connection establishment or designated when 517 the connection is manually provisioned. 519 5.1 Bi-directional 1+1 Protection 521 Under bi-directional 1+1 protection, the connection traffic is being 522 sent on both working and protection links by A and B, but received 523 only from the working link. After a failure event, signaling between 524 A and B is required to ensure that both A and B start receiving from 525 the protection link. 527 A failure event is detected by a node in the working path. Such a 528 node sends a failure indication signal towards the owner (source) of 529 the connection along the working path (using signaling described 530 below, or mechanisms provided by the lower layer). 532 The action when the source OXC is notified of a failure is as 533 follows: 535 o Start receiving from the protection path. At the same time, 536 send a Switchover Request message along the protection path 537 towards the destination OXC. This message is not explicitly 538 addressed to the destination OXC, but it carries a connection 539 ID which aids intermediate OXCs in forwarding the message along 540 the protection path towards the destination. 542 The action when the destination OXC receives a Switchover Request 543 message is follows: 545 o Start receiving from the protection path. At the same time, 546 send a Switchover Response message along the protection path 547 towards the source OXC. The forwarding of this message by 548 intermediate OXCs is based on the connection identifier 549 information. 551 5.1.1 Identifiers 553 Source ID: The IPv4 address of the source OXC (connection owner). 554 This is assumed to be unique for OXCs within the scope of the 555 restoration domain. 557 Connection index: A 32-bit identifier that uniquely identifies a 558 connection at the source. 560 Together, the Source ID and the Connection index identify a 561 connection uniquely within the scope of the restoration domain. This 562 combination is referred to as the "Connection ID" for convenience. 564 5.1.2 Node Data Structure 566 Each OXC that is the working or protection path of a connection must 567 maintain a table whose entries consist of the following information: 569 572 The Previous and Next OXC fields are 32-bit IPv4 addresses of 573 neighboring OXCs. These are the same addresses used in the IP header 574 of restoration messages sent to these neighbors. 576 At the source and destination OXCs, the Previous and Next OXC values 577 are both set to indicate the same neighbor towards the other 578 endpoint of the connection. 580 The Protection Type field indicates whether 1+1 or Shared protection 581 is being provided for the connection. 583 This table may be built when the working and protection paths of the 584 connections are provisioned using signaling, or may be configured in 585 the case of NMS-based provisioning. The table entries must remain 586 until the connection is explicitly de-provisioned. 588 5.1.3 End-to-End Failure Indication Message 590 This message is sent by an intermediate node towards the source of a 591 connection along the working path of the connection. For instance, 592 such a node might have attempted local span protection and failed 593 (this message may not be necessary if the lower layer provides 594 mechanisms for detection of connection failure by the endpoints). 596 The format of this message is as follows: 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type=0x04 | Length | Checksum | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Connection ID (Source ID) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Connection ID (Connection Index) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Consider an OXC detecting a link failure. Suppose the failed span is 607 to a neighbor whose identity is N. The OXC retrieves all table 608 entries where N is the Previous or Next OXC. Each such table entry 609 indicates the affected connection, and the above message is 610 generated for each connection. The message is sent in an IP packet 611 with the source address set to the address of the sending OXC and 612 the destination address set to the Previous OXC. 614 This message is transmitted periodically by the OXC, as controlled 615 by the configurable parameter, End-to-End Retransmission Timer. The 616 default value of this parameter is 90ms. The OXC stops transmitting 617 this message under the following conditions: 619 o A corresponding Failure Acknowledge message is received; 621 o The End-to-End Failure Indication Timer expires (the action in 622 the latter case is undefined in this draft. For instance, the 623 sending OXC may notify a management system. The default value 624 for this timer is 1 minute); or 626 o The connection is de-provisioned. 628 Each OXC in the working path receiving such a message does the 629 following. 631 - If it is the source of the indicated connection, it stops 632 propagating the message further and generates an 633 acknowledgement message (Sec. 5.1.4). 635 - If it also has originated a failure indication message for the 636 same connection, it stops re-transmitting such a message. 637 Furthermore, it also does not propagate the received failure 638 indication message further. (This action is needed when a bi- 639 directional data link failure occurs between two OXCs, say, A 640 and B. Suppose A is upstream from B (in relation to the 641 connection source). Also suppose that A has generated a failure 642 indication towards the source. If it later receives a failure 643 indication generated by B, it must suppress the retransmission 644 of failure indication messages it originated. Also, it need not 645 forward the first failure indication message originated by B. 646 Finally, it must forward failure indication acknowledge 647 messages received from the source to B (Section 5.1.4)). 649 - Otherwise, it looks up the table entry corresponding to the 650 Connection ID. 652 o If there is no table entry, the received message is 653 silently discarded. 655 o Otherwise, the Source Address in the IP header of the 656 message is compared with the Next OXC field: If there 657 is a match then the received message is sent in an IP 658 packet to the Previous OXC, with Source Address set to 659 the address of the sending OXC and Destination Address 660 set to Previous OXC. If there is no match, the received 661 message is silently discarded. 663 5.1.4 End-to-End Failure Acknowledge Message 665 This message is sent by the source OXC in response to an End-to-End 666 failure indication message. This message is sent towards the 667 originator of the failure indication message along the working path 668 of the connection. 670 The format of this message is as follows: 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type=0x05 | Length | Checksum | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Connection ID (Source ID) | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Connection ID (Connection Index) | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 This message is transmitted in response to each End-to-End Failure 681 Indication message. The source OXC always sends this message to the 682 Next OXC as found in the table entry corresponding to the Connection 683 ID. 685 Each intermediate OXC receiving such a message does the following. 687 - If it is the originator of the corresponding Failure Indication 688 message, it stops propagating the message further. 690 - Otherwise, it looks up the table entry corresponding to the 691 Connection ID. 693 o If there is no table entry, the received message is 694 silently discarded. 696 o Otherwise, the Source Address in the IP header of the 697 message is compared with the Previous OXC field: If 698 there is a match then the received message is sent in 699 an IP packet to the Next OXC, with Source Address set 700 to the address of the sending OXC and Destination 701 Address set to Next OXC. If there is no match, the 702 received message is silently discarded. 704 5.1.5 End-to-End Switchover Request Message 706 This message is generated by the source OXC receiving an indication 707 of failure in a connection. It is sent to the Next OXC along the 708 protection path. 710 The format of this message is as follows: 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Type=0x06 | Length | Checksum | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Connection ID (Source ID) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Connection ID (Connection Index) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Status | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 The Status field is set to 0x01 if the end OXC is able to switchover 723 to the protection path. Otherwise, it is set to 0x00. 725 This message is transmitted periodically by the end OXC, as 726 controlled by the configurable parameter, End-to-End Retransmission 727 Timer. The default value of this parameter is 90ms. The OXC stops 728 transmitting this message under the following conditions: 730 o A corresponding End-to-End Switchover Response message is 731 received; 733 o The End-to-End Switchover Timer expires (the default value for 734 this timer is 1 minute); or 736 o The connection is explicitly de-provisioned. 737 Each intermediate OXC receiving such a message does the following. 738 It looks up the table entry corresponding to the Connection ID: 740 o If there is no table entry, the received message is silently 741 discarded. 743 o Otherwise, if the protection type for the connection is 1+1 744 then 746 - the Source Address in the IP header of the message is 747 compared with the Previous OXC field: If there is a 748 match then the received message is sent in an IP packet 749 to the Next OXC, with Source Address set to the address 750 of the sending OXC and Destination Address set to Next 751 OXC. If there is no match, the received message is 752 silently discarded. 754 5.1.6 End-to-End Switchover Response Message 756 This message is sent by the destination OXC receiving an End-to-End 757 Switchover Request message. It is sent to the previous OXC in the 758 protection path. 760 The format of this message is as follows: 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type=0x07 | Length | Checksum | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Connection ID (Source ID) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Connection ID (Connection Index) | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Status | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 This message is transmitted in response to each End-to-End 773 Switchover Request message received. If the Status field was set to 774 0x00 in the Request message, it is set to 0x00 in this message also. 775 Otherwise, the Status field is set to 0x01 or 0x00 depending on 776 whether the sending OXC is able to switchover to the protection path 777 or not, respectively. 779 Each intermediate OXC receiving such a message does the following. 780 It looks up the table entry corresponding to the Connection ID: 782 o If there is no table entry, the received message is silently 783 discarded. 785 o Otherwise, if the protection type for the connection is 1+1 786 then 788 - the Source Address in the IP header of the message is 789 compared with the Next OXC field: If there is a match 790 then the received message is sent in an IP packet to 791 the Previous OXC, with Source Address set to the 792 address of the sending OXC and Destination Address set 793 to Previous OXC. If there is no match, the received 794 message is silently discarded. 796 5.2 Shared Protection 798 Shared protection requires prior soft-reservation of capacity along 799 the protection path. Furthermore, after a failure event, the 800 protection path must be explicitly activated. This requires actions 801 at each intermediate OXC along the protection path. It is possible 802 that a protection path may not be successfully activated when 803 multiple, concurrent failure events occur. In this case, shared 804 protection capacity may be claimed for more than one failed 805 connection and the protection path can be activated only for one of 806 them (at most). 808 For implementing shared protection, the identifier and data 809 structures related to signaling along the control path are as 810 defined for 1+1 protection in Sections 5.1.1 and 5.1.2. In addition, 811 each OXC must also keep information needed to establish the data 812 plane of the protection path. This information indicates the cross- 813 connect that must be established to activate the protection path for 814 each connection, as follows: 816 { Connection ID, , 818 } 820 The precise nature of the Port, Channel, etc. information would 821 depend on the type of OXC and connection (The Generalized MPLS 822 signaling draft describes different type of switches [3]). 824 5.2.1 End-to-End Failure Indication and Acknowledgement 826 The End-to-End failure indication and acknowledgement procedures and 827 messages are as defined in Sections 5.1.3 and 5.1.4. 829 5.2.2 End-to-End Switchover Request 831 This message is generated by the source OXC receiving an indication 832 of failure in a connection. It is sent to the Next OXC in the 833 protection path. 835 The format of this message is as follows: 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type=0x06 | Length | Checksum | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Connection ID (Source ID) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Connection ID (Connection Index) | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Status | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 The Status field is set to 0x01 if the end OXC is able to switchover 848 to the protection path. Otherwise, it is set to 0x00. 850 This message is transmitted periodically by the end OXC, as 851 controlled by the configurable parameter, End-to-End Retransmission 852 Timer. The default value of this parameter is 90ms. The OXC stops 853 transmitting this message under the following conditions: 855 o A corresponding End-to-End Switchover Response message is 856 received; 858 o The End-to-End Switchover Timer expires; or 860 o The connection is explicitly de-provisioned. 862 Each intermediate OXC receiving such a message does the following. 863 The OXC looks up the table entry corresponding to the Connection ID: 865 o If there is no table entry, the received message is silently 866 discarded. 868 o Otherwise, if the Protection Type for the connection is Shared 869 then the Source Address in the IP header of the message is 870 compared with the Previous OXC field: 872 - If there is no match then the received message is 873 silently discarded. 875 - Otherwise, 877 o The value of the received Status field is 878 checked. If it is 0x00 then the received 879 message is sent in an IP packet to the Next 880 OXC, with Source Address set to the address of 881 the sending OXC and Destination Address set to 882 Next OXC. 884 o If the received Status field is 0x01 then it is 885 checked if the protection path for the 886 connection can be activated. If so, the message 887 is passed on to the Next OXC as described 888 above. 890 o If the received Status field is 0x01, but the 891 protection path for the connection cannot be 892 activated then the message is passed on to the 893 Next OXC as described above, with the Status 894 field set to 0x00. 896 5.2.3 End-to-End Switchover Response 898 This message is sent by the destination OXC receiving an End-to-End 899 Switchover Request message. It is sent to the previous OXC in the 900 protection path. 902 The format of this message is as follows: 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type=0x09 | Length | Checksum | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Connection ID (Source ID) | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Connection ID (Connection Index) | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Status | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 This message is transmitted in response to each End-to-End 915 Switchover Request message received. If the Status field was set to 916 0x00 in the Request message, it is set to 0x00 in this message also. 917 Otherwise, the Status field is set to 0x01 or 0x00 depending on 918 whether the destination OXC is able to switchover to the protection 919 path or not, respectively. 921 Each intermediate OXC receiving such a message does the following. 922 The OXC looks up the table entry corresponding to the Connection ID: 924 o If there is no table entry, the received message is silently 925 discarded. 927 o Otherwise, if the Protection Type for the connection is 928 "shared" then the Source Address in the IP header of the 929 message is compared with the Next OXC field: 931 - If there is no match then the received message is 932 silently discarded. 933 - Otherwise, 935 o The value of the received Status field is 936 checked. If it is 0x00 then the received 937 message is sent in an IP packet to the Previous 938 OXC, with Source Address set to the address of 939 the sending OXC and Destination Address set to 940 Previous OXC. The protection path is not 941 activated in this case. 943 o If the received Status field is 0x01 then the 944 protection path for the connection is activated 945 and the message is passed on to the Previous 946 OXC as described above. 948 6. Discussion 950 6.1 Relationship between Local and End-to-End Protection Procedures 952 In general, local protection may be attempted before invoking end- 953 to-end protection. The exception to this is when end-to-end 1+1 954 protection is used for a connection. In this case, it is better to 955 directly invoke end-to-end protection since alternate path resources 956 are already active for the connection. 958 Thus, the general guideline that may be considered is to note the 959 protection type of connections in intermediate OXCs during 960 provisioning, and invoke local span protection only for working 961 links carrying connections that are not 1+1 protected end-to-end. 962 This implies that when a working link carries more than one 963 connection, all the connections must have the same end-to-end 964 protection type. The provisioning process must ensure this. If this 965 is not possible then local span protection may be invoked for 966 working links that have at least one connection that is not end-to- 967 end 1+1 protected. 969 6.2 Connection Priorities During Protection 971 The local protection procedure described in this draft switches all 972 the connections on a failed working link onto a protection link. The 973 advantage of this approach is that the signaling between OXCs is at 974 the level of links and not at the level of connections. This is 975 beneficial if a link could potentially carry a number of 976 connections. On the other hand, it limits flexibility, since a 977 working link must carry connections of similar priority. Otherwise, 978 it is not possible to ensure that higher priority connections are 979 favored over lower priority connections when a failure event affects 980 more than one working link and there are fewer protection links than 981 the number of failed working links. 983 Also, under the above failure scenario, a decision must be made as 984 to which working links (and therefore connections) are chosen to be 985 protected and in what priority order. In general, an OXC might 986 detect failures sequentially, i.e., all failed working links may not 987 be detected simultaneously, but only sequentially. In this case, as 988 per the proposed signaling procedures, connections on a working link 989 may be switched over to a given protection link, but another failure 990 (of a working link carrying higher priority connections) may be 991 detected soon afterwards. In this case, the new connections may bump 992 the ones previously switched over the protection link. 994 In the case of end-to-end shared protection, priorities may be 995 implemented for allocating shared link resources under multiple 996 failure scenarios. Note that shared protection works under the 997 assumption that the primary path of connections whose backups share 998 resources are SRLG-disjoint [1]. Under single-failure scenarios, 999 this would ensure that exactly one connection will "claim" the 1000 allocated (shared) resources. But under multiple failure scenarios, 1001 more than one connection can claim shared resources. If such 1002 resources are allocated to a lower priority connection, they may 1003 have to be reclaimed and allocated to a higher priority connection. 1004 Furthermore, the lower priority connection must be de-provisioned 1005 along the protection path (this can be done using the signaling 1006 mechanisms developed for provisioning, rather than restoration 1007 signaling). The proposed signaling mechanisms can support 1008 connection-priority based allocation of shared resources during 1009 restoration signaling (specifically, during the Switchover Response 1010 step). 1012 A way to simplify end-to-end shared protection is to allocate shared 1013 resources to connections of the same priority. This way, a 1014 connection will not be first allocated shared resources and then 1015 bumped from the protection path. 1017 6.3 Multi-Domain Restoration 1019 When an end-to-end connection follows a long path through multiple 1020 routing or administrative domains, it may be required to consider an 1021 intermediate form of restoration, called "intra-domain end-to-end 1022 restoration". With this approach, a failure within a domain would 1023 result in end-to-end restoration between the connection ingress and 1024 egress points within the domain (perhaps after local span 1025 restoration is attempted). When this fails, or if a failure occurs 1026 in an inter-domain link, full end-to-end restoration will be 1027 attempted. 1029 This type of a structured approach for restoration is particularly 1030 useful in the near term when an optical internetwork may be 1031 constructed by interconnecting multi-vendor optical subnetworks [1]. 1032 In this case, intra-domain restoration may be proprietary, with 1033 standard restoration signaling implemented between border OXCs. But 1034 this type of restoration also requires some hardware support at the 1035 border nodes. 1037 6.4 Optical mesh restoration and MPLS-based recovery 1039 Over the past year or so, there has been considerable work on 1040 MPLS-based recovery under the auspices of the MPLS WG (see, for 1041 example, [3], [5], [6], [7], [8], [9], and [10]), with a framework 1042 document [4] being adopted as a WG document. 1044 The terminology outlined at the start of this document is also 1045 explained in the MPLS-recovery framework document [4], in the 1046 context of MPLS LSP-based recovery. 1048 The failure indication message of Section 4, is quite similar to 1049 the failure indication signal (FIS) defined in [5], and elaborated 1050 on in [9] and [10]. A difference between the schemes and message 1051 formats discussed in this document and those presented in [5], 1052 [9], and [10], is that these documents focus primarily on MPLS LSP 1053 restoration. As such, the messages defined therein contain 1054 explicit label information for packet LSPs, which is not required 1055 in optical networks. Further, [5] does not specifically cover the 1056 case of the coordinated signaling required for local span 1057 protection and for M:N protection with pooled protection links, 1058 which are central to this proposal. 1060 6.5 Implementation Considerations 1062 As described in this draft, restoration signaling does not require 1063 any central actions (such as admission control or centralized 1064 resource allocation) within an OXC for end-to-end protection. Local 1065 span protection may require the consideration of all available 1066 protection link resources at the master. But end-to-end protection, 1067 which is more difficult from a latency perspective, can be 1068 controlled by distributing multiple, independent protocol instances 1069 in an OXC such that each instance covers a subset of connections 1070 passing through an OXC. Such optimizations would depend on the 1071 architecture of the systems implementing the proposed protocol. 1073 6.6 Summary of Proposed Messages and Timers 1075 The following messages were introduced in this draft: 1077 Message Type Message Name 1079 0x01 Failure Indication 1080 0x02 Switchover Request 1081 0x03 Switchover Response 1082 0x04 End-to-End Failure Indication 1083 0x05 End-to-End Failure Acknowledge 1084 0x06 End-to-End Switchover Request 1085 0x07 End-to-End Switchover Response 1087 The following timers were introduced in this draft: 1089 Timer Name Default Value Messages Governed 1091 Retransmission Timer 30 ms 1, 2 1092 Failure Indication Timer 500 ms 1 1093 Switchover Timer 500 ms 2 1094 End-to-End Retransmission Timer 90 ms 4, 6 1095 End-to-End Failure Indication Timer 1000 ms 4 1096 End-to-End Switchover Timer 1000 ms 6 1098 7. Conclusion 1100 In this draft, a signaling mechanism for fast restoration in optical 1101 mesh networks was described. The proposed mechanism consists of a 1102 protocol running directly over IP. The proposed messages are short 1103 and the interaction amongst nodes as proposed is rather simple. This 1104 proposal deals with local span protection and end-to-end protection, 1105 1+1 and shared. 1107 It is likely that the structure of the proposed mechanism would 1108 allow restoration to be completed quickly. Clearly, extensive 1109 quantitative evaluation is needed before the responsiveness of the 1110 proposed mechanism can be established. 1112 The specification of finite state machines in intermediate and end 1113 nodes for different protection modes is left for future work. 1115 References 1117 1. B. Rajagopalan, et al., "IP over Optical Networks: A Framework", 1118 draft-many-ip-optical-framework-02.txt. 1120 2. J. P. Lang, et al, ""Link Management Protocol", draft-ietf-mpls- 1121 lmp-01.txt. 1123 3. P. Ashwood-Smith, et al., "Generalized MPLS: Signaling Functional 1124 Specification," draft-ietf-mpls-generalized-signaling-01.txt. 1126 4. Makam, et al, "Framework for MPLS-based Recovery," draft-ietf- 1127 mpls-recovery-frmwrk-02.txt, February 2001. 1129 5. K. Owens et al, "A Path Protection/Restoration Mechanism for MPLS 1130 Networks," draft-chang-mpls-path-protection-02.txt, November 2000. 1132 6. Kini, S., et al, "Shared Backup Label Switched Path Restoration," 1133 draft-kini-restoration-shared-backup-00.txt, November 2000. 1135 7. Hellstrand, F., and Andersson, L., "Extensions to CR-LDP and RSVP- 1136 TE for setup of pre-established recovery tunnels," draft- 1137 hellstrand-recovery-merge-01.txt, November 2000. 1139 8. D. Haskin, Krishnan, R., "A Method for Setting up an Alternative 1140 Label Switched Path to Handle Fast Reroute," draft-haskin-mpls- 1141 fast-reroute-05.txt, November, 2000. 1143 9. K. Owens et al, "Extensions to RSVP-TE for MPLS Path Protection," 1144 draft-chang-mpls-rsvpte-path-protection-ext-01.txt, November 2000. 1146 10. K. Owens et al, "Extensions to CR-LDP for MPLS Path 1147 Protection," draft-owens-mpls-crldp-path-protection-ext-01.txt, 1148 November 2000. 1150 Author Information 1152 Bala Rajagopalan, Debanjan Saha Greg Bernstein 1153 Tellium, Inc. Ciena Corp. 1154 2 Crescent Place 10480 Ridgeview Court 1155 Ocean Port, NJ 07757 Cupertino, CA 94014 1156 Ph.: +1-732-923-4237, 4264 Ph: +1-408 366 4713 1157 Email: {braja, dsaha}@tellium.com Email: gregb@ciena.com 1159 Vishal Sharma 1160 Metanoia, Inc. 1161 335 Elan Village Lane, Unit 203 1162 San Jose, CA 95134-2539 1163 Ph: +1-408-943-1794 1164 Email: v.sharma@ieee.org