MPLS Working Group S. Matsushima, Ed.
Internet-Draft Softbank Telecom
Intended status: Standards Track T. Murakami
Expires: August 28, 2008 Cisco Systems
K. Nagami
INTEC Netcore
February 25, 2008
BGP Point to Multipoint LSP
draft-satoru-mpls-bgp-multipoint-05
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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes motivations and use cases to P2MP extension
of BGP. This extension will allow to make both Inter-AS and Intra-AS
P2MP LSP that fit to some use cases then also clarify required
features.
Matsushima, et al. Expires August 28, 2008 [Page 1]
Internet-Draft BGP P2MP LSP February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Inter-AS P2MP . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Intra-AS . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Inter-AS MVPN Option C . . . . . . . . . . . . . . . . . . 4
3.2. Carriers' Carrier P2MP routing . . . . . . . . . . . . . . 4
3.3. Over-layed Intra-AS P2MP-LSP . . . . . . . . . . . . . . . 5
4. BGP P2MP LSP . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Scalability Considerations . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Matsushima, et al. Expires August 28, 2008 [Page 2]
Internet-Draft BGP P2MP LSP February 2008
1. Introduction
For some reasons, BGP [1] is useful protocols to create Inter-AS and
Intra-AS LSPs by extending to carry MPLS label informations[2] . In
the case of Point-to-Multipoint (P2MP) LSP, suitable motivations
exist that using BGP to fit some use cases then we clarify required
features for BGP P2MP. In each use case, we assume that inter-AS
link and network uses MPLS as P2MP transport as well as intra-AS
networks.
2. Motivations
This section describes motivations of P2MP extension to BGP.
2.1. Inter-AS P2MP
Some applications that uses P2MP LSP has appeared. Service provider
is requesting the P2MP LSP connection among ASes. Inter-AS Option C
of RFC4364 [3] is used for a lot of service provider's Inter-AS
connections. In this case, it is also necessary to achieve Option C
in the Inter-AS Multicast VPN [6] environment. At this time, the
P2MP LSP connection is needed between ASes. Moreover, P2MP LSP
connection between PE and CE is preferable in the case of Carriers'
Carrier network of RFC4364 [3] as core network of VPN provider.
The method of using PCE for the P2MP LSP connection with Inter-AS is
examined. PCE offers passing calculation information necessary to
connect P2MP TE-LSP[7] in the Inter-AS environment but there is a
case where TE-LSP cannot be connected by policy of Inter-AS. In this
case, neither P2MP-TE nor PCE are applicable. On the other hand, BGP
is generally used for Inter-AS in many cases then service provider
may want to use BGP as P2MP connection as well. However, P2MP LSP
cannot be done by BGP.
2.2. Intra-AS
As for P2MP LSP that uses RSVP-TE or MLDP, signaling is done with
hop-by-hop manner. All LSRs are in Intra-AS that P2MP-LSP passes
should support these signaling then makes efficient P2MP tree.
Oppositely, there are a lot of demands of LSR that specializes P2MP
function such as signaling and packet replication be isolated from
unicast LSR to keep simple network even if it sacrifices efficiency.
In this case, Service Provider may want to establish P2MP LSPs among
P2MP LSRs as multi-hop, over-lay manner. they need to decide which
LSR become appropriate branch LSR of P2MP LSP and which is backup in
policy basis. Hence they want to decide the branch LSR explicitly in
Matsushima, et al. Expires August 28, 2008 [Page 3]
Internet-Draft BGP P2MP LSP February 2008
Intra-AS.
3. Use cases
This section describes some use case to find out required features to
BGP support P2MP ability.
3.1. Inter-AS MVPN Option C
When a VPN traverse two or more AS composing of Inter-AS Option C,
ASBRs should make LSP to PE that exists in adjacent other AS. Here,
advertising routes related to VPN customer between ASes must be done
only between RRs. This means that ASBR must be agnostic from VPN
routes. Also ASBR should maintain P-Tunnel to PE in Multicast VPN.
multihop EBGP
/---+RR1+----------------+RR2+---\
IBGP / \ IBGP
/ \
+ EBGP +
PE1---P----P---ASBR1+---+ASBR2----P---P---PE2
(AS1 side) (AS2 side)
Figure 1: MVPN Option C
RRs exchanges routes related to Multicast VPN on multihop EBGP peer
in Figure 1 , and ASBR exchanges routes related to P-Tunnel. This
route must not cntain any VPN information. Routes that ASBR
exchanges should have MPLS label that identifies P-Tunnel that should
be distinct in each ASes. It is necessary to enhance BGP for EBGP
between ASBR. Note that in the case of ingress replication P-Tunnel
type is excepted. And whole of solution to achieve MVPN Option C is
out of scope.
3.2. Carriers' Carrier P2MP routing
When a certain service provider is offering VPN MPLS backbone service
by Carriers 'Carrier (CsC), service provider maintains only CE route
in VPN. Therefore, CsC PE does not need to know VPN service routes.
This means that CsC network can scale well.
Matsushima, et al. Expires August 28, 2008 [Page 4]
Internet-Draft BGP P2MP LSP February 2008
/---RR---\
/ \
+ IBGP +
CsC EBGP CsC CsC EBGP CsC
CE1+-------+PE1------P------PE2+-------+CE2
+ +
\ multihop MVPN-EBGP/IBGP /
\-------------------------------/
Figure 2: P2MP Carriers' Carrier
In CsC network shown in Figure 2, CsC-PEs should offer MPLS P2MP
transport so that CsC CE may need MPLS P2MP connectivity with remote
CE when CsC CE does Multicast service or Multicast VPN service. If
CsC CE1 does source CE and MVPN-BGP[8], CsC CE1 advertises Auto-
discovery route to CsC CE2 on MVPN-IBGP. At this time, it is
necessary to deliver Tunnel identifier specified in PMSI Tunnel
attribute to CsC-CE2 via CsC-PE1, RR, and CsC-PE2.
Similarly, it is necessary to deliver Tunnel identifier advertised
with Leaf auto-discovery route on MVPN-IBGP to CsC-CE1 via CsC-PE2,
RR, and CsC-PE1 as for CsC-CE2. CsC PEs should bind P2MP tree of
internal with LSP between CsC PE to CsC CEs. It is necessary to
enhance BGP with these functions. Note that the case where CsC-CE1
and CsC-PE1 do ingress replication is excluded.
When CsC-PEs aggregate two or more CsC-CEs into a P2MP transport to
improve scalability, leaf CsC-PE2 will receive even a packet not
necessary as a result. De-multiplexer that takes out a necessary
packet is needed from received packets. CsC-PE2 can forward packet
to CsC-CE2 when received packet have label that local assigned to
bind CsC-CE2. CsC-PE1 can forward packet when receive routes that
include label to push onto shared P2MP transport. And then that
label is bind with CsC-CE1, CsC-PE1 can forward packet that received
from CsC-CE1 to CsC-PE2.
3.3. Over-layed Intra-AS P2MP-LSP
It might be difficult for SP that wants to keep simple own network in
some cases to give backbone multicast and/or P2MP ability in existing
MPLS network. As for such SP, the P2MP ability might be given to
specific LSR, and may select way to separate service that needs
packet replication from existing LSR though it somewhat sacrifices
optimization of packet replication.
Matsushima, et al. Expires August 28, 2008 [Page 5]
Internet-Draft BGP P2MP LSP February 2008
RR1
/ \
/ \
CE1------PE1------P1----P3-----P5----P2------PE3------CE3
\ / | | \ /
\ /--/ BLSR1 | \ /--/
\----\ | BLSR2 \---\
/ \ | | / \
CE2------PE2------P2----P4-----P6----P8------PE4------CE4
\ /
\ /
RR2
Figure 3: Over-layed Intra-AS P2MP LSRs
Network shown in Figure 3 starts offering CE1-CE4 Multicast VPN
service by PE1-PE4, P1-P8, BLSR1, and 2 belonging and using P2MP LSP
for same domain. In this network, only BLSR1 and 2 have P2MP branch
capability, and P1-P8 doesn't have the P2MP ability. PE1-PE4 can
become source and leaf of P2MP LSP. When PE1 becomes source PE and
P2MP LSP is configured to PE3 and PE4, LSP is as follows.
PE1---->BLSR1---->PE3
|
+------>PE4
Unicast LSP overlays P2MP LSP between each PE and BLSR. For
instance, PE1--> BLSR1 exists on unicast LSP that passes
PE1->P1->P3->BLSR1. MPLS label that shows P2MP LSP becomes bottom
stack label. If unicast LSP is TE-LSP, becomes possible to
protection by Fast Reroute and to do the traffic engineering.
BGP may be used to establish P2MP LSP onto unicast LSP of each PE and
BLSR in stack. It is necessary to enhance BGP for P2MP LSP. Because
one unicast LSP can carry two or more P2MP LSP in stack, scalability
of P router can be improved than hop-by-hop P2MP protocols.
Moreover, it is possible to prepare for outage of P2MP node by policy
based operation to which BLSR and/or source PE that becomes backup
because it uses BGP are provided beforehand. Detail of BGP
extensions are described with following section.
4. BGP P2MP LSP
Concrete P2MP informations that is carry by BGP and procedures are
further study.
Matsushima, et al. Expires August 28, 2008 [Page 6]
Internet-Draft BGP P2MP LSP February 2008
5. Scalability Considerations
The number of EBGP peering of ASBR and IBGP full mesh in AS give
scalability impact even though BGP is originally excellent protocol
in scalability. In use case described in Section 3, Route reflector
(RR) [4] be able to use instead of full mesh of IBGP. At that time,
necessary routes must not be summarize by RR. Moreover, BGP
maintains control plane only, and is not used for data plane.
As for BGP P2MP routes, the number of BGP P2MP routes may be
increased by increasing LSPs and LSRs. To avoid or mitigate such
increasing that may affect to scalability, RT Constraint [9] may
appropriate for some cases.
6. Security Considerations
As well as RFC3107 [2] describes, P2MP LSP using BGP has the "label
spoofing" problem. For this, BGP LSR which also support P2MP LSP
should not make the adjacencies of both trusted and untrusted system
on the same interface.
7. Acknowledgments
Thanks to Miya Kohno and Paul Doolan for their support and helpful
comments.
8. References
8.1. Normative References
[1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[2] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4",
RFC 3107, May 2001.
[3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[4] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
April 2006.
[5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
Matsushima, et al. Expires August 28, 2008 [Page 7]
Internet-Draft BGP P2MP LSP February 2008
8.2. Informative References
[6] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen,
E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in progress),
January 2008.
[7] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to
Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
for Point-to-Multipoint TE Label Switched Paths (LSPs)",
RFC 4875, May 2007.
[8] Aggarwal, R., "BGP Encodings and Procedures for Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-04 (work
in progress), November 2007.
[9] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R.,
Patel, K., and J. Guichard, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)",
RFC 4684, November 2006.
Authors' Addresses
Satoru Matsushima (editor)
Softbank Telecom Corp.
9-1, Higashi-Shinbashi 1-chome
Minato-ku
Tokyo 105-7316
Japan
Email: satoru@ft.solteria.net
Tetsuya Murakami
Cisco Systems
2-1-1, Nishi-Shinjuku
Shinjuku-ku
Tokyo 163-0409
Japan
Email: tmurakam@cisco.com
Matsushima, et al. Expires August 28, 2008 [Page 8]
Internet-Draft BGP P2MP LSP February 2008
Kenichi Nagami
INTEC Netcore, Inc.
1-3-3, Shin-suna
Koto-ku
Tokyo 135-0075
Japan
Email: nagami@inetcore.com
Matsushima, et al. Expires August 28, 2008 [Page 9]
Internet-Draft BGP P2MP LSP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Matsushima, et al. Expires August 28, 2008 [Page 10]