MPLS Working Group S. Matsushima, Ed. Internet-Draft Japan Telecom Expires: December 28, 2006 T. Murakami Cisco Systems K. Nagami INTEC Netcore June 26, 2006 BGP Point to Multipoint LSP draft-satoru-mpls-bgp-multipoint-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies the way that is to make policy based point to multipoint (p2mp) LSP using BGP. BGP update message is used to notify to consult which is a p2mp LSP's ingress, branch, egress LSRs, and indicate upstream node of LSP with MPLS label information from downstream LSR. Matsushima, et al. Expires December 28, 2006 [Page 1] Internet-Draft BGP P2MP LSP June 2006 1. Introduction The BGP speakers which are Label Switched Router (LSR) distribute label mapping information for a particular route in piggybacked in the BGP route. Suppose that the LSP in this manner is multipoint to point(mp2p) LSP[1]. At the same time, the situation in which the label for point to multipoint LSP is also piggybacked in the BGP route which indicates p2mp route information is useful. This document specifies the way that is to make policy based point to multipoint (p2mp) LSP using BGP. BGP update message is used to notify to consult which is a p2mp LSP's ingress, branch, egress LSRs, and indicate upstream node of LSP with MPLS label information from downstream LSR. Matsushima, et al. Expires December 28, 2006 [Page 2] Internet-Draft BGP P2MP LSP June 2006 2. Motivations When Service Provider(SP) want to establish p2mp-LSP in their network, they should consider which node is appropriate branch node for egress LSRs, how to prepare which node is backup of branch node, how to inform wihch p2mp LSP is exist in another AS and/or which p2mp LSP is needed to another AS. In these requirements and situations, BGP capabilities that policy based path selection and inter-AS route distribution are attractive to operate p2mp LSP. But current BGP specification is not applicable to p2mp LSP. Thus, to provide policy based and inter-AS capability to p2mp LSP, some BGP specifications are extended. Matsushima, et al. Expires December 28, 2006 [Page 3] Internet-Draft BGP P2MP LSP June 2006 3. BGP Point-to-Multipoint LSP Informations The BGP p2mp LSP information should be distributed in BGP update message. The BGP extended community[2] and NLRI are used to distinguish particular p2mp LSP. This information should be propagated to BGP speakers which need to make p2mp LSP. The BGP p2mp LSR should have p2mp-instance that import p2mp routes as downstream of particular LSP. When p2mp-instance receives packets from upstream LSR, it should replicate and send packets to its downstream entries. The BGP p2mp LSP information is following: o P2MP_ID (Extended Community attribute) This attribute is used to identify the address or administrative number of P2MP-LSP. The ingress node and branch LSR shall advertise this attribute to the network. o P2MP_BRANCH_LIST (Extended Community attribute) This attribute is used to identify the sequence of the branch LSRs of P2MP-LSP. The branch LSR shall add its router-id or address this attribute to the route from its upstream branch LSR. If branch LSR receives routing information that doesn't have this attribute, the branch LSR shall create a new P2MP_BRANCH_LIST attribute and then advertise it to the network. o P2MP_IMPORTED_BRANCH (Extended Community attribute) This attribute is used to identify the upstream LSR at egress and/or branch LSR of P2MP-LSP. The egress node and the branch node shall advertise this attribute to the network, containing the Router-ID of its upstream LSR. o NLRI The NLRI of p2mp route should be indicating p2mp node with MPLS label.There are two case of usage for the NLRI in the p2mp route. In the case of notify a ingress LSR and branch LSRs of p2mp LSP, it is used to identify the ingress LSR, then ingress LSR's router-id is in the NLRI with null MPLS label. In other case that egress and branch LSR notify its upstream, the NLRI should be used to indicate itself, then its router-id is in the NLRI with a MPLS label. Note that the p2mp NLRI shold have capability to distinguish each LSP even if an p2mp router have several p2mp LSPs. Matsushima, et al. Expires December 28, 2006 [Page 4] Internet-Draft BGP P2MP LSP June 2006 4. P2MP instance The BGP speaker which supports p2mp branch capability should have p2mp-instance for each of p2mp LSP. The p2mp-instance should have one upstream entry and several downstream entries. When the BGP LSR has p2mp-instance, a MPLS label should be mapped to it to receive packets from its upstream. Then if the BGP LSR imports particular p2mp routes, a p2mp-instance should have this route as downstream entries. The BGP LSR receives the packet which are imposed upstream label of particular p2mp-instace, a p2mp-instance should pop label, replicate it and push the label onto the packet's label stack to each of downstream entries. If downstream LSR is not connected directly, push the label which mapped interior LSP to BGP nxext hop onto the packet's label stack, and then send the packet to each downstream. Matsushima, et al. Expires December 28, 2006 [Page 5] Internet-Draft BGP P2MP LSP June 2006 5. Procedure 5.1. Making p2mp LSP tree The following actions complete making the tree of p2mp LSP in the network. In these step, the ingress LSR doesn't forward packets to any of branch and egress LSR even if the ingress LSR receives packets toward p2mp LSP. This step makes only the p2mp tree. This could be an advantage of operation because the operator can confirm and modify the tree before the packet traverse LSP. 1. Advertising of ingress and branch LSR First of all, the node that is becoming ingress LSR should advertise p2mp LSP routing information that including P2MP_ID community. The branch LSR that receives the routing information from the ingress LSR will update it with adding its router-id to P2MP_BRANCH_LIST and ORIGINATOR_ID[3]. When branch LSR re- advertise p2mp LSP route, the NEXT_HOP attribute is branch LSR's address. 2. Tree of P2MP-LSP decision Each of branch LSR which receives these routes eshould select the best path in which branch LSR is its upstream based on its path selection rule or manual configuration. Then branch LSRs should re-advertise its p2mp route with P2MP_BRANCH_LIST where its route-id is added. It also includes upstream routers as P2MP_BRANCH_LIST. 3. Loop Prevention The p2mp route will be advertised repeatedly, and it will flow back to original branch LSR. In this case, each branch LSR should check whether the received route include its router-id as P2MP_BRANCH_LIST or not. If it includes itself, branch LSR should discard such routes to avoid routing loop. 5.2. Join to P2MP LSP When the egress LSR wants to receive packets from p2mp LSP, it selects the most appropriate upstream branch based on its path selection rule or manual configuration. And egress LSR should advertise the route with original P2MP_ID and P2MP_IMPORTED_BRANCH attribute that indicate its upstream branch LSR. At this time, the next hop of advertises route indicates its address. When the branch LSR receives the route that include P2MP_IMPORTED_BRANCH, which indicate its local router-id, the branch LSR should import this route Matsushima, et al. Expires December 28, 2006 [Page 6] Internet-Draft BGP P2MP LSP June 2006 to local p2mp instance related to each p2mp LSP. The branch LSR imports routes from the egress node, it also advertises P2MP_IMPORTED_BRANCH which indicates its upstream of P2MP-LSP. This action is repeated to propagate upstream information. 5.3. Leave from P2MP LSP When the egress LSR and/or the branch LSR leave from p2mp LSP, they should stop importing of downstream routes and withdraw the route. It will include both P2MP_IMPORTED_BRANCH, and P2MP_BRANCH_LIST attribute if the node is branch LSR. This action causes the upstream LSR to discard the route from leaving downstream LSR, and then the LSR can leave from p2mp LSP. Moreover, the branch LSR can leave automatically if it doesn't have any route in local p2mp instance. Matsushima, et al. Expires December 28, 2006 [Page 7] Internet-Draft BGP P2MP LSP June 2006 6. Security Considerations As well as RFC3107 [1] describes, p2mp LSP using BGP has the "label spoofing" problem. For this reason, BGP LSR which also support p2mp LSP should not adjacent both of trusted and untrusted system on the same interface. Matsushima, et al. Expires December 28, 2006 [Page 8] Internet-Draft BGP P2MP LSP June 2006 7. Acknowledgments Thanks to Miya Kohno for helpful comments. 8. References [1] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [2] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [3] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. Matsushima, et al. Expires December 28, 2006 [Page 9] Internet-Draft BGP P2MP LSP June 2006 Authors' Addresses Satoru Matsushima (editor) Japan Telecom Co.,LTD. 9-1 Higashi-Shinbashi 1-chome Tokyo 105-7316 Japan Email: satoru@ft.solteria.net Tetsuya Murakami Cisco Systems Email: tmurakam@cisco.com Kenichi Nagami INTEC Netcore, Inc. Email: nagami@inetcore.com Matsushima, et al. Expires December 28, 2006 [Page 10] Internet-Draft BGP P2MP LSP June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Matsushima, et al. Expires December 28, 2006 [Page 11]