Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6513

Multicast in MPLS/BGP IP VPNs

Pages: 88
Proposed Standard
Errata
Updated by:  758279007988
Part 5 of 5 – Pages 75 to 88
First   Prev   None

Top   ToC   RFC6513 - Page 75   prevText

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 || ++=============++ ++=============++ ++=============++
Top   ToC   RFC6513 - Page 76
   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.
Top   ToC   RFC6513 - Page 77
   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 || ++=============++ ++=============++ ++=============++
Top   ToC   RFC6513 - Page 78

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
Top   ToC   RFC6513 - Page 79
   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.
Top   ToC   RFC6513 - Page 80
   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.
Top   ToC   RFC6513 - Page 81

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.
Top   ToC   RFC6513 - Page 82
   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.
Top   ToC   RFC6513 - Page 83
   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.
Top   ToC   RFC6513 - Page 84

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.
Top   ToC   RFC6513 - Page 85
   [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.
Top   ToC   RFC6513 - Page 86
   [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.
Top   ToC   RFC6513 - Page 87

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
Top   ToC   RFC6513 - Page 88

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