Internet Engineering Task Force X. Tu Internet-Draft Z. Fu Intended status: Standards Track K. Li Expires: July 2, 2012 ZTE Corporation December 30, 2011 Resource Reservation Protocol - Traffic Engineering(RSVP-TE) Extensions for Inter-AS P2MP TE LSPs draft-tfl-mpls-rsvp-te-inter-as-p2mp-00 Abstract [RFC4875] describes extensions to RSVP-TE protocol for building a P2MP TE LSP in MPLS/GMPLS network environment.However, [RFC4875] doesn't specify path selecting problem of inter-AS P2MP TE LSP.This document specifies an inter-AS P2MP path computation method based on extentions to RSVP-TE Protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 2, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Tu, et al. Expires July 2, 2012 [Page 1] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Procedures Overview . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Egress ASBR Node . . . . . . . . . . . . . . . . . . . . . 6 3.3. Ingress ASBR Node . . . . . . . . . . . . . . . . . . . . 6 3.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Leaf Node . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Path Message . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Resv message . . . . . . . . . . . . . . . . . . . . . . . 9 5. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. S2L_SUB_LSP_COST Object . . . . . . . . . . . . . . . . . 11 5.2. S2L_SUB_LSP_HOPS Object . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. Class Numbers and C-Types . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Tu, et al. Expires July 2, 2012 [Page 2] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 1. Introduction [RFC4875] describes extensions to RSVP-TE protocol for building a P2MP TE LSP in MPLS/GMPLS network environment. However, [RFC4875] doesn't specify path selecting problem of inter-AS P2MP TE LSP. In inter-AS scenario, node maybe have not topology and resources of the whole network, so it may be not able to compute an inter-AS P2MP TE LSP. This document specifies an inter-AS P2MP path bulding method based on extentions to RSVP-TE Protocol. Inter-AS P2MP LSP is comprised of multiple source-to-leaf(S2L) sub-LSPS, which are set up between the ingress and egress LSRs located in different ASes. Tu, et al. Expires July 2, 2012 [Page 3] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 2. Terminology AS: Autonomous System, A collection of connected routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet. ASBR: Autonomous System Border Router. Routers used to connect together ASes of the same or different service providers via one or more inter-AS links. Ingress ASBR of AS(n): an ASBR connecting AS(n-1) to AS(n) on a path. Egress ASBR of AS(n): an ASBR connecting AS(n) to AS(n+1) on a path. Tu, et al. Expires July 2, 2012 [Page 4] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 3. Procedures Overview 3.1. Overview This document specifies an inter-AS P2MP path bulding method using RSVP-TE Protocol Extension. Using this method, the ingress node will start the intra-AS P2MP TE LSP building process, and distribute the PATH message according to RSVP-TE protocol extension specified in [RFC4875]. Egress ASBRs will transmit the PATH request message of a P2MP TE LSP to the ingress ASBRs of the neighbor ASes, which will processes the message as an request for intra-AS P2MP TE LSP building request, and continuing the building process. Following text describes this mechanism. 1. Ingress node treats egress ASBRs and leaf nodes in the same AS as leaf nodes of the intra-AS P2MP tree, and computes P2MP path to those leaf nodes.. Since it is intra-AS path computation, current existing mature solutions could be used here. 2. Ingress node uses RSVP-TE protocol to construct Path messages and send them through the path that has been computed to leaf nodes in the same AS. The Path message should contain path information to leaf nodes and cost information of S2L sub-LSPs. 3. When egress ASBR node receives path request message, it should first decide whether or not cost value of path in the message is smaller than that exists on the node. If yes, egress ASBR node should save the Path message and update cost value, then transmit the Path message to ingress ASBR nodes of downstream neighbor AS. Otherwise, egress ASBR node should desert the Path message without any process. 4. When ingress ASBR node of neighbor AS receives Path message, it should first decide whether or not cost value of path in the message is smaller than that exists on the node. If yes, ingress ASBR node should save the later received path message and compute path to all egress ASBRs and leaf nodes in the same AS, after computation is finished, ingress node construct Path messages and send them through the path that has been computed to leaf nodes in the same AS. This is similar to step 1 and 2. 5. When egress node receives Path message, it should first decide whether or not cost value of path in the message is smaller than that exists on the node, if yes, then it should further decide the interface that received the newly path request message is not the same interface that has been used to reply, if yes, egress node should save the newly Path message, waits for a Delay time and then reserves resources and assigns label, replies Resv Tu, et al. Expires July 2, 2012 [Page 5] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 message to corresponding upstream node. 6. Resv message passes through the path that Path message used, reaches ingress ASBR node and upstream neighbor AS's egress ASBR node, those ASBR nodes need reserve resources, assign label for upstream node, and transmit new Resv message to upstream node. 7. Ingress node receives Resv message, configures received label to the node. Then, an inter-AS S2L sub-LSP for one leaf node is set up. 3.2. Egress ASBR Node When egress ASBR receivers PATH messages, it should process the message according to following procedures. It should first decide whether or not the cost value of S2L sub-LSP in the messages is smaller than the pre-saved one. if yes, egress ASBR node should desert the Path message without any further process. Otherwise, egress ASBR must replace the pre-saved PATH request messages with the newly received messages. if links that connect to these ingress ASBR nodes could satisfy TE attributions, egress ASBR node will transmit Path message to these ingress ASBR nodes. The Path message treats egress ASBR node as root and ingress ASBR node of next neighbor AS as leaf node, and cost value of path in the Path message equals cost value of path in the Path message that egress ASBR node received plus cost value of the link between egress ASBR node and ingress ASBR node. When Egress ASBR receives Resv message, it should process the message according to following procedures. If it has replied the corresponding P2MP TE LSP, it only needs to configure label to the node. If not, it should also reserve resources and assign label, construct new Resv message and reply Resv message to corresponding upstream node. If this node receives more than one Resv messages, it should merge flow descriptors of those messages and reply single Resv message to corresponding upstream node. 3.3. Ingress ASBR Node Ingress ASBR node receives Path message, it should process the message according to following procedures. It should first decide whether or not cost value of path in the message isn't smaller than that exists on the node, if yes, ingress ASBR node should desert the path message without any further process. Tu, et al. Expires July 2, 2012 [Page 6] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 Otherwise, ingress ASBR node should save the Path message. If this is first Path message received, ingress ASBR node would compute optimal multicast tree between it and every egress ASBR node or egress PE node in the same AS; if this is not the first message received, ingress ASBR node could use computation result which has been computed. Then, ingress ASBR node computes cost value of path between it and each egress ASBR node or egress PE node, constructs new Path message, sends the message to every egress ASBR node and egress PE node. Ingress ASBR node receives Resv message, it should process the message according to following procedures. If it has replied the corresponding P2MP TE LSP, it only needs to configure label to the node. If not, it should also reserve resources and assign label, construct new Resv message and reply Resv message to corresponding egress ASBR node of upstream neighbor AS. If this node receives more than one Resv messages, it should merge flow descriptors of those messages and reply single Resv message to corresponding egress ASBR node of upstream neighbor AS. 3.4. Transit Node Transit node receives Path message, it should process the message according to following procedures. It should first decide whether or not cost value of path in the message isn't smaller than that exists on the node, if yes, Transit node should desert the path message without any further process. Otherwise, transit node should update the message that saved on the node, and analyze the message and process it according to procedures defined in RFC4875, then transmit it to downstream node. Transit node receives Resv message, it should process the message according to following procedures. If it has replied the corresponding P2MP TE LSP, it only needs to configure label to the node. If not, it should also reserve resources and assign label, construct new Resv message and reply Resv message to corresponding upstream node. If this node receives more than one Resv messages, it should merge flow descriptors of those messages and reply single Resv message to corresponding upstream node. 3.5. Leaf Node Leaf node receives Path message, it should process the message according to following procedures. Tu, et al. Expires July 2, 2012 [Page 7] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 Leaf node should first decide whether or not this is the first message received, if yes, leaf node should start timer. If this isn't the first message, and timer doesn't expire, leaf node should decide if cost value of path in the message is smaller than that exists on the node, if yes, leaf node should update the message that saved on the node. If cost value in the message is not smaller, leaf node should desert the message. If this is not the first message but timer expires, leaf node should desert the message. If timer expires, leaf node should reserve resources and assign label, and reply Resv message to upstream node. Tu, et al. Expires July 2, 2012 [Page 8] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 4. Messages Format 4.1. Path Message Path message is used to transmit path setup request, [RFC4875] gives a detailed definition. This document gives extensions to Path message, and Path message could also transmit cost or hops of path which is from root node to certain transit node or leaf node. The format of Path message is as follows. ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [] ::= [ ] ::= | [ ] In each object, there is a or object, they are used to describe cost of a path. 4.2. Resv message Resv message is used to reply Path message and assign label for upstream node, [RFC4875] gives a detailed definition. This document gives extentions to Resv message, and Resv message could also transmit cost or hops of path which is from root node to leaf node. The format of Resv message is as follows. Tu, et al. Expires July 2, 2012 [Page 9] Internet-Draft RSVP-TE Extensions for inter-AS P2MP Path December 2011 ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ] [ ] [ ... ]