idnits 2.17.1 draft-tfl-mpls-rsvp-te-inter-as-p2mp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC4875]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 30, 2011) is 4473 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) == Unused Reference: 'RFC2205' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC6037' is defined on line 429, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Tu 3 Internet-Draft Z. Fu 4 Intended status: Standards Track K. Li 5 Expires: July 2, 2012 ZTE Corporation 6 December 30, 2011 8 Resource Reservation Protocol - Traffic Engineering(RSVP-TE) Extensions 9 for Inter-AS P2MP TE LSPs 10 draft-tfl-mpls-rsvp-te-inter-as-p2mp-00 12 Abstract 14 [RFC4875] describes extensions to RSVP-TE protocol for building a 15 P2MP TE LSP in MPLS/GMPLS network environment.However, [RFC4875] 16 doesn't specify path selecting problem of inter-AS P2MP TE LSP.This 17 document specifies an inter-AS P2MP path computation method based on 18 extentions to RSVP-TE Protocol. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 2, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Procedures Overview . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Egress ASBR Node . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Ingress ASBR Node . . . . . . . . . . . . . . . . . . . . 6 72 3.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.5. Leaf Node . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Path Message . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2. Resv message . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1. S2L_SUB_LSP_COST Object . . . . . . . . . . . . . . . . . 11 79 5.2. S2L_SUB_LSP_HOPS Object . . . . . . . . . . . . . . . . . 11 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7.1. Class Numbers and C-Types . . . . . . . . . . . . . . . . 13 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 [RFC4875] describes extensions to RSVP-TE protocol for building a 91 P2MP TE LSP in MPLS/GMPLS network environment. However, [RFC4875] 92 doesn't specify path selecting problem of inter-AS P2MP TE LSP. In 93 inter-AS scenario, node maybe have not topology and resources of the 94 whole network, so it may be not able to compute an inter-AS P2MP TE 95 LSP. 97 This document specifies an inter-AS P2MP path bulding method based on 98 extentions to RSVP-TE Protocol. Inter-AS P2MP LSP is comprised of 99 multiple source-to-leaf(S2L) sub-LSPS, which are set up between the 100 ingress and egress LSRs located in different ASes. 102 2. Terminology 104 AS: Autonomous System, A collection of connected routing prefixes 105 under the control of one or more network operators that presents a 106 common, clearly defined routing policy to the Internet. 108 ASBR: Autonomous System Border Router. Routers used to connect 109 together ASes of the same or different service providers via one or 110 more inter-AS links. 112 Ingress ASBR of AS(n): an ASBR connecting AS(n-1) to AS(n) on a path. 114 Egress ASBR of AS(n): an ASBR connecting AS(n) to AS(n+1) on a path. 116 3. Procedures Overview 118 3.1. Overview 120 This document specifies an inter-AS P2MP path bulding method using 121 RSVP-TE Protocol Extension. Using this method, the ingress node will 122 start the intra-AS P2MP TE LSP building process, and distribute the 123 PATH message according to RSVP-TE protocol extension specified in 124 [RFC4875]. Egress ASBRs will transmit the PATH request message of a 125 P2MP TE LSP to the ingress ASBRs of the neighbor ASes, which will 126 processes the message as an request for intra-AS P2MP TE LSP building 127 request, and continuing the building process. Following text 128 describes this mechanism. 130 1. Ingress node treats egress ASBRs and leaf nodes in the same AS as 131 leaf nodes of the intra-AS P2MP tree, and computes P2MP path to 132 those leaf nodes.. Since it is intra-AS path computation, 133 current existing mature solutions could be used here. 135 2. Ingress node uses RSVP-TE protocol to construct Path messages and 136 send them through the path that has been computed to leaf nodes 137 in the same AS. The Path message should contain path information 138 to leaf nodes and cost information of S2L sub-LSPs. 140 3. When egress ASBR node receives path request message, it should 141 first decide whether or not cost value of path in the message is 142 smaller than that exists on the node. If yes, egress ASBR node 143 should save the Path message and update cost value, then transmit 144 the Path message to ingress ASBR nodes of downstream neighbor AS. 145 Otherwise, egress ASBR node should desert the Path message 146 without any process. 148 4. When ingress ASBR node of neighbor AS receives Path message, it 149 should first decide whether or not cost value of path in the 150 message is smaller than that exists on the node. If yes, ingress 151 ASBR node should save the later received path message and compute 152 path to all egress ASBRs and leaf nodes in the same AS, after 153 computation is finished, ingress node construct Path messages and 154 send them through the path that has been computed to leaf nodes 155 in the same AS. This is similar to step 1 and 2. 157 5. When egress node receives Path message, it should first decide 158 whether or not cost value of path in the message is smaller than 159 that exists on the node, if yes, then it should further decide 160 the interface that received the newly path request message is not 161 the same interface that has been used to reply, if yes, egress 162 node should save the newly Path message, waits for a Delay time 163 and then reserves resources and assigns label, replies Resv 164 message to corresponding upstream node. 166 6. Resv message passes through the path that Path message used, 167 reaches ingress ASBR node and upstream neighbor AS's egress ASBR 168 node, those ASBR nodes need reserve resources, assign label for 169 upstream node, and transmit new Resv message to upstream node. 171 7. Ingress node receives Resv message, configures received label to 172 the node. Then, an inter-AS S2L sub-LSP for one leaf node is set 173 up. 175 3.2. Egress ASBR Node 177 When egress ASBR receivers PATH messages, it should process the 178 message according to following procedures. 180 It should first decide whether or not the cost value of S2L sub-LSP 181 in the messages is smaller than the pre-saved one. if yes, egress 182 ASBR node should desert the Path message without any further process. 183 Otherwise, egress ASBR must replace the pre-saved PATH request 184 messages with the newly received messages. if links that connect to 185 these ingress ASBR nodes could satisfy TE attributions, egress ASBR 186 node will transmit Path message to these ingress ASBR nodes. The 187 Path message treats egress ASBR node as root and ingress ASBR node of 188 next neighbor AS as leaf node, and cost value of path in the Path 189 message equals cost value of path in the Path message that egress 190 ASBR node received plus cost value of the link between egress ASBR 191 node and ingress ASBR node. 193 When Egress ASBR receives Resv message, it should process the message 194 according to following procedures. 196 If it has replied the corresponding P2MP TE LSP, it only needs to 197 configure label to the node. If not, it should also reserve 198 resources and assign label, construct new Resv message and reply Resv 199 message to corresponding upstream node. If this node receives more 200 than one Resv messages, it should merge flow descriptors of those 201 messages and reply single Resv message to corresponding upstream 202 node. 204 3.3. Ingress ASBR Node 206 Ingress ASBR node receives Path message, it should process the 207 message according to following procedures. 209 It should first decide whether or not cost value of path in the 210 message isn't smaller than that exists on the node, if yes, ingress 211 ASBR node should desert the path message without any further process. 213 Otherwise, ingress ASBR node should save the Path message. If this 214 is first Path message received, ingress ASBR node would compute 215 optimal multicast tree between it and every egress ASBR node or 216 egress PE node in the same AS; if this is not the first message 217 received, ingress ASBR node could use computation result which has 218 been computed. Then, ingress ASBR node computes cost value of path 219 between it and each egress ASBR node or egress PE node, constructs 220 new Path message, sends the message to every egress ASBR node and 221 egress PE node. 223 Ingress ASBR node receives Resv message, it should process the 224 message according to following procedures. 226 If it has replied the corresponding P2MP TE LSP, it only needs to 227 configure label to the node. If not, it should also reserve 228 resources and assign label, construct new Resv message and reply Resv 229 message to corresponding egress ASBR node of upstream neighbor AS. 230 If this node receives more than one Resv messages, it should merge 231 flow descriptors of those messages and reply single Resv message to 232 corresponding egress ASBR node of upstream neighbor AS. 234 3.4. Transit Node 236 Transit node receives Path message, it should process the message 237 according to following procedures. 239 It should first decide whether or not cost value of path in the 240 message isn't smaller than that exists on the node, if yes, Transit 241 node should desert the path message without any further process. 242 Otherwise, transit node should update the message that saved on the 243 node, and analyze the message and process it according to procedures 244 defined in RFC4875, then transmit it to downstream node. 246 Transit node receives Resv message, it should process the message 247 according to following procedures. 249 If it has replied the corresponding P2MP TE LSP, it only needs to 250 configure label to the node. If not, it should also reserve 251 resources and assign label, construct new Resv message and reply Resv 252 message to corresponding upstream node. If this node receives more 253 than one Resv messages, it should merge flow descriptors of those 254 messages and reply single Resv message to corresponding upstream 255 node. 257 3.5. Leaf Node 259 Leaf node receives Path message, it should process the message 260 according to following procedures. 262 Leaf node should first decide whether or not this is the first 263 message received, if yes, leaf node should start timer. 265 If this isn't the first message, and timer doesn't expire, leaf node 266 should decide if cost value of path in the message is smaller than 267 that exists on the node, if yes, leaf node should update the message 268 that saved on the node. If cost value in the message is not smaller, 269 leaf node should desert the message. 271 If this is not the first message but timer expires, leaf node should 272 desert the message. 274 If timer expires, leaf node should reserve resources and assign 275 label, and reply Resv message to upstream node. 277 4. Messages Format 279 4.1. Path Message 281 Path message is used to transmit path setup request, [RFC4875] gives 282 a detailed definition. This document gives extensions to Path 283 message, and Path message could also transmit cost or hops of path 284 which is from root node to certain transit node or leaf node. The 285 format of Path message is as follows. 287 ::= [ ] 288 [ [ | ] ...] 289 [ ] 290 291 292 [ ] 293 294 [ ] 295 [ ... ] 296 [ ] 297 [ ] 298 [ ] 299 [ ... ] 300 301 [] 303 ::= 304 [ ] 306 ::= 307 | 308 [ ] 310 In each object, there is a 311 or object, they are used to 312 describe cost of a path. 314 4.2. Resv message 316 Resv message is used to reply Path message and assign label for 317 upstream node, [RFC4875] gives a detailed definition. This document 318 gives extentions to Resv message, and Resv message could also 319 transmit cost or hops of path which is from root node to leaf node. 320 The format of Resv message is as follows. 322 ::= [ ] 323 [ [ | ] ... ] 324 [ ] 325 326 327 [ ] [ ] 328 [ ] 329 [ ] 330 [ ... ] 331