idnits 2.17.1 draft-matsuura-reverse-lsp-02.txt: 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. 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.) -- The document date (February 2003) is 7731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LSP-HIERARCHY' is mentioned on line 128, but not defined == Missing Reference: 'GMPLS-RSVP' is mentioned on line 188, but not defined == Unused Reference: 'RFC3473' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'MPLS-HIERARCHY' is defined on line 231, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Matsuura 3 Internet Draft E. Oki 4 Document: draft-matsuura-reverse-lsp-02.txt NTT 5 Expiration Date: August 2003 6 February 2003 8 Signaling Reverse-directional LSP in Generalized MPLS 10 draft-matsuura-reverse-lsp-02.txt 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. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-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 To view the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 27 Directory, see http://www.ietf.org/shadow.html. 29 Abstract 31 This document defines an extension to Generalized MPLS signaling 32 procedure to support the establishment of reverse-directional LSPs. 33 Reverse-directional LSPs can be signaled by "one-way" signaling. 35 1. Introduction 37 Generalized MPLS extends the MPLS control plane to encompass 38 bidirectional LSPs. Support of Upstream Label provides reduction 39 of the setup latency for successful establishment of bidirectional 40 LSPs. Signaling of reverse-directional LSPs is derived from the 41 support of Upstream Label and it can be considered as a reasonable 42 generalization of the MPLS functionalities. This memo presents a 43 functional description of the extensions for signaling reverse- 44 directional LSPs. 46 2. Reverse-directional LSPs 48 Generalized MPLS supports the establishment of bidirectional 49 LSPs [RFC3471, RFC3472, RFC3472]. For the support of bidirectional 50 LSPs, the concept of Upstream Label is introduced. As per these 51 Internet Drafts, in the remainder of this document, the term 52 "initiator" is used to refer to a node that starts the establishment 53 of an LSP and the term "terminator" is used to refer to the node 54 that is the target of the LSP. 56 An initiator node sends a Path/Request message, which includes 57 an Upstream Label object/TLV indicating a request for the 58 establishment of a bidirectional LSP. When a message containing 59 an Upstream Label is received, an intermediate node allocates a 60 label on the outgoing interface and establishes internal data 61 paths before filling in an outgoing Upstream Label and 62 propagating the Path/Request message. Terminator nodes process 63 Path/Request messages as usual, with the exception that the 64 upstream label can immediately be used to transport data 65 traffic associated with the LSP towards the initiator. Note 66 that a resource reservation correlating with the upstream 67 direction must be done during the Path/Request processing on 68 each node. 70 The procedure referred above implies possible functionality for 71 the signaling of reverse-directional LSPs. In this document, 72 the term "reverse-directional LSP" is used to refer to a 73 unidirectional LSP that transports data traffic from the 74 terminator to the initiator. The term "forward-directional LSP" 75 is used to refer a unidirectional LSP that transports data 76 traffic from the initiator to the terminator. This document 77 presents a functional description of the extensions for 78 signaling these unidirectional LSPs. 80 A label allocation between two nodes should be executed on a 81 responsibility of the node which receives datagram bound to the 82 label. Therefore it is rather rational that a receiver of data 83 traffic initiates an establishment of an LSP. 85 The most remarkable advantage of reverse-directional signaling 86 is fast setup of LSPs. The time between the beginning of a 87 signaling and the establishment of a data path is reduced by 88 half compared with forward-directional signaling. It is also 89 helpful to reduce the occupation of network resources by LSPs, 90 especially for “short-hold” LSPs. 92 In addition, in a case of failure of LSPs, it is usually 93 detected earlier　by nodes in receiver side with respect to data 94 traffic. Thus, receiver-oriented initiation of LSPs is easy to 95 work in cooperation with a failure handling. 97 3. Signaling procedures 99 In Generalized MPLS signaling, the presence of Upstream Label 100 indicates the LSP to be set up is bidirectional. Similarly, 101 Upstream Label object/TLV is used for the establishment of 102 reverse-directional LSPs. 104 An initiator node sends a Path/Request messages including not 105 only an Upstream Label but also one “null” Label Set object/TLV, 106 i.e., a Label Set object/TLV which has only one null label as 107 an inclusive list. When the Path/Request message reaches the 108 terminator node, a reverse-directional LSP has been already 109 usable. For this LSP, the terminator node does not need to send 110 Resv/Mapping messages any longer. 112 When an initiator uses ERO label subobjects/TLVs, two label 113 subobjects/TLVs, i.e., one label with the U-bit set and one 114 null label without the U-bit set, following the first address 115 subobject/TLV are sufficient. Because these label 116 subobjects/TLVs are copied to the Upstream Label and Label Set 117 respectively, in consequent Path/Request messages. 119 The node originating an Upstream Label must ensure that the 120 Upstream Label is consistent with the Generalized Label Request 121 object/TLV in the Path/Request message. When an LSR receives a 122 Path/Request message containing an Upstream Label and a null 123 Label Set, it should confirm the existence of an appropriate 124 link, on which it transports data traffic using received 125 Upstream Label, before propagating the Path/Request message. 127 Such a consideration can be also applied to the signaling of 128 hierarchical LSP [LSP-HIERARCHY]. When an LSR receives a 129 Path/Request message, and decides it is at the edge of a region 130 with respect to the ERO carried in the message, it must 131 determine the other edge of the region. If a new FA-LSP is 132 required to be set up between the LSR and the other edge of the 133 region, the LSR can initiates the setup of a new reserve- 134 directional FA-LSP “concurrently”. That is, the LSR may send 135 the Path/Request messages simultaneously, one for the original 136 reverse-directional LSP to the other edge of the region, and 137 the other for new reserve-directional FA-LSPs to next hops 138 along the FA-LSP’s path. On the other edge of the region, when 139 the LSR receives these two Path/Request messages, it can 140 forward the Path/Request message for the original LSP to its 141 next hop. Because the receipt of the Path/Request message for 142 the new FA-LSP implies that the new FA-LSP is already usable. 144 In deletion of reverse-directional LSPs, there are two cases, 145 described here for RSVP specifications. When an initiator node 146 inserts an Admin Status Object in a Path message and sets the 147 R-bit and D-bit, the terminator node responds with a PathErr 148 message with the Path_State_Removed flag set. When a terminator 149 node inserts an Admin Status Object in a Resv message and sets 150 the R-bit and D-bit, the initiator node sends a PathTear 151 message downstream to remove the LSP. 153 4. Applications 155 There are three possible application of the signaling reverse- 156 directional LSPs. In the first, it is used to establish a 157 single reverse-directional LSP. In the second, it can be used 158 as parts of establishment of asymmetrical bidirectional LSPs. 159 The final application is an alternative method for 160 establishment of forward-directional LSPs, and it is an RSVP 161 specific mechanism. 163 4.1 Reverse-directional LSP 165 For general purposes of use of networks, a receiver of data 166 traffic may want to be an initiator of the signaling. In such a 167 case, a node issues a Path/Request message which includes both 168 of an Upstream Label and a null Label Set. At the point in time 169 when the Path/Request message is processed by the terminator 170 node, a reverse-directional LSP setup is completed. 172 4.2 Asymmetric bidirectional LSP 174 When a node, which is signaling an establishment of bi- 175 directional LSP, can not find an appropriate pair of labels on 176 an identical link, it may intend the LSP to diverge into 177 different routes. Instead of issuing Error messages, the node 178 sends two Path/Request messages, one for a forward-directional 179 LSP and the other for a reverse-directional LSP, on different 180 outgoing interfaces. Since this approach may bring some 181 complexity to the signaling, it should be applied to only some 182 limited conditions, for instance, when there is no 183 subobject/TLV last in ERO/ER-Hop besides the terminator node. 185 4.3 Pseudo forward-directional LSP 187 The procedure described below is RSVP-TE specific. It is based 188 on the Notification message extension [GMPLS-RSVP]. 190 For some reasons, it is useful that a sender of data traffic 191 leaves a receiver an initiation of a signaling. For example, 192 when a sender node does not have sufficient perspective of 193 label (resource) availabilities along the route on which the 194 LSP is set up, it may be an immediate and probable way to 195 establish a forward-directional LSP from the sender’s point of 196 view. 198 A sender node of data traffic pretends a terminator of 199 signaling of a reverse-directional LSP. The sender sends an 200 unsolicited Notify message to the receiver node, requesting the 201 receiver to initiate signaling a reverse-directional LSP from 202 the receiver’s point of view. The Notify message is targeted 203 the receiver directly e.g., by means of an IP encapsulation. 204 The Notify message must include a MESSAGE_ID object and an 205 ADMIN_STATUS object with R bit set to 0. Information required 206 for the consequent Path message, except for an UPSTREAM_LABEL 207 object, is enveloped in a POLICY_DATA object. The IP address of 208 the sender is included in an ERROR_SPEC object. An error code 209 for indication of "Unsolicited Notify message" is TBA, and 210 error values for this application are TBD. When the Notify 211 message is received, the receiver returns an Ack message to the 212 sender, and initiates a signaling for a reverse-directional LSP 213 immediately. 215 Security Considerations 217 This document raises no new security concerns. 219 References 221 [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - 222 Signaling Functional Description", RFC 3471, IETF Proposed 223 Standard, January 2003. 225 [RFC3472] L.Berger (Editor) et al., "Generalized MPLS Signaling - 226 CR-LDP Extensions", RFC 3472, IETF Proposed Standard, January 2003. 228 [RFC3473] L.Berger (Editor) et al., "Generalized MPLS Signaling - 229 RSVP-TE Extensions", RFC 3473, IETF Proposed Standard, January 2003. 231 [MPLS-HIERARCHY] Kompella, K. et al, “LSP Hierarchy with 232 Generalized MPLS TE”, Internet Draft, draft-ietf-mpls-lsp- 233 hierarchy-08.txt, September 2002. (work in progress) 235 Author's Addresses 237 Nobuaki Matsuura 238 NTT Corporation 239 3-9-11 Midori, Musashino 240 Tokyo, Japan 180-8585 241 Phone: +81 422 59 3758 242 Email: matsuura.nobuaki@lab.ntt.co.jp 244 Eiji Oki 245 NTT Corporation 246 3-9-11 Midori, Musashino 247 Tokyo, Japan 180-8585 248 Phone: +81 422 59 3441 249 Email: oki.eiji@lab.ntt.co.jp