RFC 6513
Multicast in MPLS/BGP IP VPNs
12. Encapsulations
The BGP-based auto-discovery procedures will ensure that the PEs in a single MVPN only use tunnels that they can all support, and for a given kind of tunnel, that they only use encapsulations that they can all support.12.1. Encapsulations for Single PMSI per P-Tunnel
12.1.1. Encapsulation in GRE
GRE encapsulation can be used for any PMSI that is instantiated by a mesh of unicast P-tunnels, as well as for any PMSI that is instantiated by one or more PIM P-tunnels of any sort. Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network +---------------+ | P-IP Header | +---------------+ | GRE | ++=============++ ++=============++ ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++
The IP Protocol Number field in the P-IP header MUST be set to 47. The Protocol Type field of the GRE header is set to either 0x800 or 0x86dd, depending on whether the C-IP header is IPv4 or IPv6, respectively. When an encapsulated packet is transmitted by a particular PE, the source IP address in the P-IP header must be the same address that the PE uses to identify itself in the VRF Route Import Extended Communities that it attaches to any of VPN-IP routes eligible for UMH determination that it advertises via BGP (see Section 5.1). If the PMSI is instantiated by a PIM tree, the destination IP address in the P-IP header is the group P-address associated with that tree. The GRE key field value is omitted. If the PMSI is instantiated by unicast P-tunnels, the destination IP address is the address of the destination PE, and the optional GRE key field is used to identify a particular MVPN. In this case, each PE would have to advertise a key field value for each MVPN; each PE would assign the key field value that it expects to receive. [RFC2784] specifies an optional GRE checksum and [RFC2890] specifies an optional GRE sequence number fields. The GRE sequence number field is not needed because the transport layer services for the original application will be provided by the C-IP header. The use of the GRE checksum field must follow [RFC2784]. To facilitate high speed implementation, this document recommends that the ingress PE routers encapsulate VPN packets without setting the checksum or sequence fields.12.1.2. Encapsulation in IP
IP-in-IP [RFC2003] is also a viable option. The following diagram shows the progression of the packet as it enters and leaves the service provider network.
Packets received Packets in transit Packets forwarded
at the ingress PE in the service by the egress PEs
provider network
+---------------+
| P-IP Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
When the P-IP header is an IPv4 header, its Protocol Number field is
set to either 4 or 41, depending on whether the C-IP header is an
IPv4 header or an IPv6 header, respectively.
When the P-IP header is an IPv6 header, its Next Header field is set
to either 4 or 41, depending on whether the C-IP header is an IPv4
header or an IPv6 header, respectively.
When an encapsulated packet is transmitted by a particular PE, the
source IP address in the P-IP header must be the same address that
the PE uses to identify itself in the VRF Route Import Extended
Communities that it attaches to any of VPN-IP routes eligible for UMH
determination that it advertises via BGP (see Section 5.1).
12.1.3. Encapsulation in MPLS
If the PMSI is instantiated as a P2MP MPLS LSP or a MP2MP LSP, MPLS
encapsulation is used. Penultimate-hop-popping MUST be disabled for
the LSP.
If other methods of assigning MPLS labels to multicast distribution
trees are in use, these multicast distribution trees may be used as
appropriate to instantiate PMSIs, and appropriate additional MPLS
encapsulation procedures may be used.
Packets received Packets in transit Packets forwarded
at the ingress PE in the service by the egress PEs
provider network
+---------------+
| P-MPLS Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
12.2. Encapsulations for Multiple PMSIs per P-Tunnel
The encapsulations for transmitting multicast data messages when there are multiple PMSIs per P-tunnel are based on the encapsulation for a single PMSI per P-tunnel, but with an MPLS label used for demultiplexing. The label is upstream-assigned and distributed via BGP as specified in Section 4. The label must enable the receiver to select the proper VRF and may enable the receiver to select a particular multicast routing entry within that VRF.12.2.1. Encapsulation in GRE
Rather than the IP-in-GRE encapsulation discussed in Section 12.1.1, we use the MPLS-in-GRE encapsulation. This is specified in [MPLS-IP]. The GRE protocol type MUST be set to 0x8847. (The reason for using the unicast rather than the multicast value is specified in [MPLS-MCAST-ENCAPS]).12.2.2. Encapsulation in IP
Rather than the IP-in-IP encapsulation discussed in Section 12.1.2, we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP]. The IP protocol number field MUST be set to the value identifying the payload as an MPLS unicast packet. (There is no "MPLS multicast packet" protocol number.)12.3. Encapsulations Identifying a Distinguished PE
12.3.1. For MP2MP LSP P-Tunnels
As discussed in Section 9, if a multicast data packet is traveling on a unidirectional C-tree, it is highly desirable for the PE that receives the packet from a PMSI to be able to determine the identity of the PE that transmitted the data packet onto the PMSI. The encapsulations of the previous sections all provide this information, except in one case. If a PMSI is being instantiated by an MP2MP LSP, then the encapsulations discussed so far do not allow one to determine the identity of the PE that transmitted the packet onto the PMSI. Therefore, when a packet traveling on a unidirectional C-tree is traveling on a MP2MP LSP P-tunnel, it MUST carry, as its second label, a label that has been bound to the packet's ingress PE. This label is an upstream-assigned label that the LSP's root node has bound to the ingress PE and has distributed via the PE Distinguisher
Labels attribute of a PMSI A-D route (see Section 4). This label will appear immediately beneath the labels that are discussed in Sections 12.1.3 and 12.2. A full specification of the procedures for advertising and for using the PE Distinguisher Labels attribute in this case is outside the scope of this document.12.3.2. For Support of PIM-BIDIR C-Groups
As was discussed in Section 11, when a packet belongs to a PIM-BIDIR multicast group, the set of PEs of that packet's VPN can be partitioned into a number of subsets, where exactly one PE in each partition is the Upstream PE for that partition. When such packets are transmitted on a PMSI, unless the procedures of Section 11.2.3 are being used, it is necessary for the packet to carry information identifying a particular partition. This is done by having the packet carry the PE Distinguisher Label corresponding to the Upstream PE of one partition. For a particular P-tunnel, this label will have been advertised by the node that is the root of that P-tunnel. (A full specification of the procedures for advertising PE Distinguisher Labels is out of the scope of this document.) This label needs to be used whenever a packet belongs to a PIM-BIDIR C-group, no matter what encapsulation is used by the P-tunnel. Hence, the encapsulations of Section 12.2 MUST be used. If the P-tunnel contains only one PMSI, the PE label replaces the label discussed in Section 12.2. If the P-tunnel contains multiple PMSIs, the PE label follows the label discussed in Section 12.2. In general, PE Distinguisher Labels can be carried if the encapsulation is MPLS, MPLS-in-IP, or MPLS-in-GRE. However, procedures for advertising and using PE Distinguisher Labels when the encapsulation is LDP-based MP2P MPLS is outside the scope of this specification.12.4. General Considerations for IP and GRE Encapsulations
These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.12.4.1. MTU (Maximum Transmission Unit)
It is the responsibility of the originator of a C-packet to ensure that the packet is small enough to reach all of its destinations, even when it is encapsulated within IP or GRE.
When a packet is encapsulated in IP or GRE, the router that does the
encapsulation MUST set the DF bit in the outer header. This ensures
that the decapsulating router will not need to reassemble the
encapsulating packets before performing decapsulation.
In some cases, the encapsulating router may know that a particular
C-packet is too large to reach its destinations. Procedures by which
it may know this are outside the scope of the current document.
However, if this is known, then:
- If the DF bit is set in the IP header of a C-packet that is known
to be too large, the router will discard the C-packet as being
"too large" and follow normal IP procedures (which may require
the return of an ICMP message to the source).
- If the DF bit is not set in the IP header of a C-packet that is
known to be too large, the router MAY fragment the packet before
encapsulating it and then encapsulate each fragment separately.
Alternatively, the router MAY discard the packet.
If the router discards a packet as too large, it should maintain
Operations, Administration, and Maintenance (OAM) information related
to this behavior, allowing the operator to properly troubleshoot the
issue.
Note that if the entire path of the P-tunnel does not support an MTU
that is large enough to carry the a particular encapsulated C-packet,
and if the encapsulating router does not do fragmentation, then the
customer will not receive the expected connectivity.
12.4.2. TTL (Time to Live)
The ingress PE should not copy the TTL field from the payload IP
header received from a CE router to the delivery IP or MPLS header.
The setting of the TTL of the delivery header is determined by the
local policy of the ingress PE router.
12.4.3. Avoiding Conflict with Internet Multicast
If the SP is providing Internet multicast, distinct from its VPN
multicast services, and using PIM based P-multicast trees, it must
ensure that the group P-addresses that it used in support of MVPN
services are distinct from any of the group addresses of the Internet
multicasts it supports. This is best done by using administratively
scoped addresses [ADMIN-ADDR].
The group C-addresses need not be distinct from either the group
P-addresses or the Internet multicast addresses.
12.5. Differentiated Services
The setting of the DS (Differentiated Services) field in the delivery IP header should follow the guidelines outlined in [RFC2983]. Setting the Traffic Class field [RFC5462] in the delivery MPLS header should follow the guidelines in [RFC3270]. An SP may also choose to deploy any of additional Differentiated Services mechanisms that the PE routers support for the encapsulation in use. Note that the type of encapsulation determines the set of Differentiated Services mechanisms that may be deployed.13. Security Considerations
This document describes an extension to the procedures of [RFC4364], and hence shares the security considerations described in [RFC4364] and [RFC4365]. When GRE encapsulation is used, the security considerations of [MPLS-IP] are also relevant. Additionally, the security considerations of [RFC4797] are relevant as it discusses implications on packet spoofing in the context of BGP/MPLS IP VPNs. The security considerations of [MPLS-HDR] apply when MPLS encapsulation is used. This document makes use of a number of control protocols: PIM [PIM-SM], BGP [MVPN-BGP], mLDP [MLDP], and RSVP-TE [RSVP-P2MP]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. If one uses the UDP-based protocol for switching to S-PMSI (as specified in Section 7.4.2), then an S-PMSI Join message (i.e., a UDP packet with destination port 3232 and destination address ALL-PIM- ROUTERS) that is not received over a PMSI (e.g., one received directly from a CE router) is an illegal packet and MUST be dropped. The various procedures for P-tunnel construction have security issues that are specific to the way that the P-tunnels are used in this document. When P-tunnels are constructed via such techniques as PIM, mLDP, or RSVP-TE, each P or PE router receiving a control message MUST ensure that the control message comes from another P or PE router, not from a CE router. (Interpreting an mLDP or PIM or RSVP- TE control message from a CE router as referring to a P-tunnel would be a bug.) A PE MUST NOT accept BGP routes of the MCAST-VPN address family from a CE.
If BGP is used as a CE-PE routing protocol, then when a PE receives
an IP route from a CE, if this route carries the VRF Route Import
Extended Community, the PE MUST remove this Community from the route
before turning it into a VPN-IP route. Routes that a PE advertises
to a CE MUST NOT carry the VRF Route Import Extended Community.
An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE
control message that attempts to extend a P-tunnel from one SP's
domain into another SP's domain. This is perfectly valid if there is
an agreement between the SPs to jointly provide an MVPN service. In
the absence of such an agreement, however, this could be an
illegitimate attempt to intercept data packets. By default, an ASBR
MUST NOT allow P-tunnels to extend beyond AS boundaries. However, it
MUST be possible to configure an ASBR to allow this on a specified
set of interfaces.
Many of the procedures in this document cause the SP network to
create and maintain an amount of state that is proportional to
customer multicast activity. If the amount of customer multicast
activity exceeds expectations, this can potentially cause P and PE
routers to maintain an unexpectedly large amount of state, which may
cause control and/or data plane overload. To protect against this
situation, an implementation should provide ways for the SP to bound
the amount of state it devotes to the handling of customer multicast
activity.
In particular, an implementation SHOULD provide mechanisms that allow
an SP to place limitations on the following:
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF
- total number of P-tunnels per VRF used for S-PMSIs
- total number of P-tunnels traversing a given P router
A PE implementation MAY also provide mechanisms that allow an SP to
limit the rate of change of various MVPN-related states on PEs, as
well as the rate at which MVPN-related control messages may be
received by a PE from the CEs and/or sent from the PE to other PEs.
An implementation that provides the procedures specified in Sections
10.1 or 10.2 MUST provide the capability to impose an upper bound on
the number of Source Active A-D routes generated and on how
frequently they may be originated. This MUST be provided on a per-
PE, per-MVPN granularity.
Lack of the mechanisms that allow an SP to limit the rate of change of various MVPN-related states on PEs, as well as the rate at which MVPN-related control messages may be received by a PE from the CEs and/or sent from the PE to other PEs may result in the control plane overload on the PE, which in turn would adversely impact all the customers connected to that PE, as well as to other PEs. See also the Security Considerations section of [MVPN-BGP].14. IANA Considerations
Section 7.4.2 defines the "S-PMSI Join message", which is carried in a UDP datagram whose port number is 3232. This port number had already been assigned by IANA to "MDT port". The reference has been updated to this document. IANA has created a registry for the "S-PMSI Join message Type Field". Assignments are to be made according to the policy "IETF Review" as defined in [RFC5226]. The value 1 has been registered with a reference to this document. The description reads "PIM IPv4 S-PMSI (unaggregated)". [PIM-ATTRIB] establishes a registry for "PIM Join attribute Types". IANA has assigned the value 1 to the "MVPN Join Attribute" with a reference to this document. IANA has assigned SAFI 129 to "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" with a reference to this document and [MVPN-BGP].15. Acknowledgments
Significant contributions were made Arjen Boers, Toerless Eckert, Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Giuliano, Shankar Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony Speakman, Dan Tappan.
16. References
16.1. Normative References
[MLDP] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [MPLS-HDR] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-IP] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [MPLS-MCAST-ENCAPS] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. [MPLS-UPSTREAM-LABEL] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [PIM-ATTRIB] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008. [PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. [RSVP-OOB] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP- TE Label Switched Paths", RFC 6511, February 2012. [RSVP-P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.16.2. Informative References
[ADMIN-ADDR] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [BIDIR-PIM] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. [BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. [MVPN-REQ] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC 4797, January 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Contributing Authors
Sarveshwar Bandi Motorola Vanenburg IT park, Madhapur, Hyderabad, India EMail: sarvesh@motorola.com Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ycai@cisco.com Thomas Morin France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@francetelecom.com Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: yakov@juniper.net IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ice@cisco.com Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
Editors' Addresses
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: raggarwa_1@yahoo.com