idnits 2.17.1 draft-lang-mpls-rsvp-oxc-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance 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 1 longer page, the longest (page 3) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 336 looks like a reference -- Missing reference section? '2' on line 338 looks like a reference -- Missing reference section? '3' on line 342 looks like a reference -- Missing reference section? '4' on line 345 looks like a reference -- Missing reference section? '5' on line 348 looks like a reference -- Missing reference section? '6' on line 351 looks like a reference -- Missing reference section? '7' on line 354 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jonathan P. Lang (Chromisys) 3 Internet Draft Krishna Mitra (Chromisys) 4 Expiration Date: September 2000 John Drake (Chromisys) 6 Extensions to RSVP for optical networking 8 draft-lang-mpls-rsvp-oxc-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 [1]. 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 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference 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. Abstract 33 Dynamically provisionable optical crossconnects (OXCs) will play an 34 active role in future optical networks and the MPL(ambda)S control 35 plane will be used to establish, teardown, and reroute optical 36 trails through the network. This document specifies extensions to 37 RSVP to address some of the unique requirements of such optical 38 trails. Specifically, we propose extensions to RSVP that allow an 39 upstream node to make a Label suggestion to a downstream node when 40 establishing an optical trail and allow both directions of a bi- 41 directional optical trail to be established simultaneously. A new 42 message type is also defined so that an RSVP node can notify 43 (possibly non-adjacent) RSVP nodes when network failures occur, 44 without affecting the RSVP states of intermediate RSVP nodes. 45 Finally, we propose a modification to allow bundle messages to be 46 sent to non-adjacent RSVP nodes. 48 3. Conventions used in this document 50 In this document, we follow the naming convention of [2] and use OXC 51 to refer to all categories of optical crossconnects, irrespective of 52 the internal switching fabric. We use the term source node to refer 53 to an RSVP node that initiates the optical trail establishment and 54 the term destination node to refer to the RSVP node that terminates 55 the trail at the other end of the network. Furthermore, we call the 56 message path from the source node to the destination node the 57 downstream direction and the reverse path from the destination node 58 back to the source node the upstream direction. Note that for bi- 59 directional connections our terminology is such that there is only 60 one source node and one destination node. 62 4. Introduction 64 Future optical networks will consist of label switched routers 65 (LSRs) and optical crossconnects (OXCs) that internetwork using the 66 MPL(ambda)S control plane. Support for provisioning and restoration 67 of end-to-end optical trails within this type of network imposes new 68 requirements on the signaling protocols. Specifically, optical 69 trails will require small setup latency, support for bi-directional 70 trails, and rapid restoration of trails in case of network failures. 71 This document builds on work already done for traffic engineering in 72 MPLS and proposes solutions for these requirements. 74 The modifications proposed in this document enhance the extensions 75 of RSVP-TE [3] to support the following functions: 76 1. Reduction of trail establishment latency by allowing 77 resources to be configured in the downstream direction. 78 2. Establishment of bi-directional trails as a single process 79 instead of establishing two uni-directional trails, one in 80 each direction, each being a separate process. Normally, 81 both directions of a bi-directional trail have the same 82 traffic engineering requirements and need to be routed over 83 the same physical route. As a result, they cannot be treated 84 as two separate trail requests. 85 3. Fast failure notification to a node responsible for trail 86 restoration can be achieved so that restoration techniques 87 can be quickly initiated. For example, for end-to-end path 88 restoration, the source is responsible for rerouting failed 89 trails, and must be notified when the trail's resources are 90 involved in a failure. 92 The organization of the remainder of this document is as follows. 93 In Section 5, we propose a Label suggestion to reduce the trail 94 establishment latency. In Section 6, we present modifications to 95 RSVP so that both directions of a bi-directional trails can be 96 provisioned simultaneously. In Section 7, we introduce a new Notify 97 message that is to notify nodes when failures occur in the network. 98 Finally, in Section 8, we discuss a modification to the bundle 99 message [3] to allow transmission between non-adjacent nodes. 101 5. Label suggestion 103 Currently in RSVP, the Label object for an optical trail is returned 104 in the Resv message. A unique feature of OXCs is that selecting a 105 (fiber, lambda) Label (see [4]) for a trail requires configuring the 106 OXC so that an input is switched to an output, and all data that 107 arrives over the input must go to the same output. This is 108 different from traditional LSRs where multiple flows from the same 109 input maybe be assigned different Labels and subsequently switched 110 to different outputs. A consequence of this is that when an OXC is 111 initially configured, Labels can be assigned to each input and 112 output and protocols (such as LMP [5]) can be used to exchange Label 113 mappings between adjacent nodes. 115 A consequence of the inherent receiver-oriented nature of RSVP is 116 that the internal configuration of an OXC in the downstream 117 direction cannot be initiated until it receives the Resv message 118 from the downstream node. The ability to begin configuring an OXC 119 before receiving a Label object in the Resv message can provide a 120 significant reduction in the setup latency, especially in OXCs with 121 non-negligible configuration time. 123 To accomplish this, we propose that an upstream OXC suggest a 124 (fiber, lambda) Label for the downstream node to use by including 125 the suggested Label object in the Label Request object [3] of the 126 Path message. The Label object will contain the downstream node�s 127 Label for the bearer channel, which can be obtained through the Link 128 Management Protocol (LMP) [5]. This will allow the upstream OXC to 129 begin its internal configuration before receiving the Resv message 130 from the downstream node. If, however, the downstream node ignores 131 the suggested Label and passes a different Label upstream, the 132 upstream OXC must reconfigure itself so that it uses the label 133 specified by the downstream node. 135 5.1. Label Request 137 The LABEL_REQUEST object format is shown below, where we have 138 defined a new C_Type for a suggested Label. 140 Class = 19, C_Type = 5 (suggested label) 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Link Media Type | L3PID | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Label Object | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Link Media Type: 151 The Link Media Type is the two-octet media type values in IS-IS/OSPF 152 Link Media Type TLV defined in [4]. 154 L3PID: 155 The L3PID is an identifier of the layer 3 protocol using this path. 156 Standard Ethertype values are used. 158 Label Object: 159 The Label object is the suggested Label for the downstream node. 161 6. Bidirectional Optical Paths 163 In future optical networks, it may be desirable to establish bi- 164 directional optical paths across the network. Using RSVP-TE [3], 165 this requires establishing two unidirectional paths: an initial path 166 from the source to the destination and a subsequent path from the 167 destination back to the source. This approach has two 168 disadvantages: the latency to establish the bi-directional path 169 requires three source/destination transit times, and the time window 170 between reserving the resources in the downstream direction and 171 reserving them in the upstream direction may be large (as much as 172 two times the source/destination transit time), decreasing the 173 probability of successfully establishing the overall bi-directional 174 path. 176 To address the disadvantages of establishing bi-directional paths 177 using current techniques in RSVP, we propose that a Label object is 178 added to the Path message in the downstream direction. In this way, 179 the upstream direction of the bi-directional path is established on 180 the first pass from the source to the destination, reducing the 181 latency of the reservation process. Furthermore, if suggested 182 Labels are used for the downstream direction of the bi-directional 183 path (see Section 5), then the time between reserving resources in 184 the upstream and downstream directions can be eliminated, increasing 185 the overall probability of success for the bi-directional path. 187 The format of the Path message is as follows (where we assume the 188 extensions of [3] are also implemented): 190 ::= [ ] 191 [] 192 [