Internet DRAFT - draft-tao-mpls-pim-interworking
draft-tao-mpls-pim-interworking
INTERNET-DRAFT B. Tao, Ed.
Intended Status: Standards Track Huawei Technologies Inc.
Expires: April 2, 2014 Others
October 2, 2013
MPLS PIM Inter-working
draft-tao-mpls-pim-interworking-02
Abstract
This document describes a framework for the inter-working between
Protocol Independent Multicast [PIM] and a leaf-driven MPLS P2MP
tunnel signaling protocol so that multiple PIM sites around an MPLS
network can form a single PIM domain without compromising PIM's
features, scalability, and performance.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 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
B. Tao et al. Expires April 2, 2014 [Page 1]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Purpose of This Work . . . . . . . . . . . . . . . . . . . 5
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
2. An Overview: PIM MPLS Inter-working . . . . . . . . . . . . . 6
2.1 PIM-SM, PIM-SSM and PIM-BiDir States . . . . . . . . . . . . 6
2.2 PIM-MPLS Border Router(mPMBR) . . . . . . . . . . . . . . . 7
2.3 A Reference Model for PIM-MPLS Inter-working(PMIW) . . . . . 8
2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding . . . . . . . 10
2.3.2 PIM Support for QPI and M-Flow Spec Binding . . . . . . 10
2.3.3 M-Flow Spec Binding Policies . . . . . . . . . . . . . . 11
2.3.4 IP Multicast Packet Forwarding at an mPMBR . . . . . . . 11
2.4 Impacted PIM messages and procedures . . . . . . . . . . . . 11
2.4.1 PIM Hello and Adjacency Over MPLS Backbone . . . . . . . 11
2.4.2 PIM Assert and Message . . . . . . . . . . . . . . . . . 12
2.4.3 PIM hop-by-hop Bootstrapping and Message . . . . . . . . 12
2.4.4 PIM Unicast Messages and C-RP Advertisement . . . . . . 12
2.4.5 PIM RP Register and RegisterStop . . . . . . . . . . . . 13
2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS . . 13
2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel . . . 13
3 Algorithms and Procedures . . . . . . . . . . . . . . . . . . . 14
3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It . 14
3.1.1. In-Band Tunnel Signaling at Leaf LER . . . . . . . . . 16
3.1.2. In-Band Tunnel Signaling at Transit LSR . . . . . . . . 17
3.1.3. In-Band Tunnel Signaling at Root LER . . . . . . . . . 18
3.1.4. Considerations for Load Balance and Traffic
Engineering(TE) . . . . . . . . . . . . . . . . . . . . 18
3.2. Operational Procedures for PIM RPT to SPT switch . . . . . 18
4. M-Flow Spec Format . . . . . . . . . . . . . . . . . . . . . . 19
5 OAM&P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 23
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1 Normative References . . . . . . . . . . . . . . . . . . . 23
8.2 Informative References . . . . . . . . . . . . . . . . . . 23
B. Tao et al. Expires April 2, 2014 [Page 2]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 24
B. Tao et al. Expires April 2, 2014 [Page 3]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
1 Introduction
1.1 Background
IP multicast sources and their receivers can be located at multiple
separated sites which are around an MPLS network. PIM, the most
popular IP multicast protocol, runs in each of these sites. A
requirement therefore is to use the MPLS tunnels to "connect" these
multiple PIM sites as if they were in a single PIM domain.
Currently there are a few standards to achieve this, most of them for
multicast VPN(mVPN) cases:
a) [RFC6513] and [RFC6514] use a third protocol, the extended
BGP, to discover multicast routes and other states from
each PIM site, propagate to other sites, and establish
P2MP tunnels in the MPLS backbone to support VPN multicast
within MPLS backbone.
b) [I-D.lin-mrsvp-te-mvpn] uses an mRSVP-TE [mRSVP-TE]
tunnel within MPLS to transparently multicast both PIM's
control and data traffic to other VPN sites, and if
necessary, establishes a separated P2MP tunnel for each
individual multicast flow. This is an out-of-band method
to signal VPN PIM states over MPLS backbone. In this way,
separated PIM sites of a VPN form a single PIM domain in
the VPN, and PIM adjacencies each pair of MPLS edge routers
are maintained across the MPLS backbone.
c) [I-D.Wijnands-mldp-inband] uses in-band signaling to build
mLDP P2MP tunnels to support (S, G) and (*, G) multicast
states. Currently, the draft only specifies the encoding and
decoding for the above two types of multicast states. It
relies on a third protocol to signal PIM ASM related states.
These methods, however, either depends on using BGP and new
extensions, or support only a limited portion of PIM features for a
particular MPLS P2MP protocol, or has limited scale and efficiency
within MPLS.
[RFC6513] extends BGP to support PIM features across an MPLS backbone
for multicast VPN cases. This dependency requires the deployment of
BGP and its extensions, as well as the associated OAM&P.
The extra protocol involvement also introduces more interactions
among protocols and thus causes additional overheads to BGP. For
example, [RFC6513] uses a BGP discovery phase on a PIM join state
B. Tao et al. Expires April 2, 2014 [Page 4]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
before a tunnel can be signaled in the MPLS backbone. This adds a
delay to the dynamic tunnel signaling.
The out-of-bound method limits itself as a solution for only certain
cases because: a) It applies to a particular MPLS signaling protocol
[mRSVP-TE]; b) Fully meshed PIM adjacencies make PIM procedures to
cross MPLS costly thus limits the solution to be used under limited
scale (See [RFC6517]); c) The default tunnel may not be optimally
routed within MPLS and its usage prevents flexible load balancing and
traffic engineering at tunnel level; only limited aggregation can be
done on (S, G) data tunnels; d) For PIM RPT to SPT switch, new
procedures and messages are introduced.
In the third solution, the supported PIM features are limited and the
solution is limited to [mLDP] as the MPLS signaling protocol.
See [RFC6517] for more information.
1.2 Purpose of This Work
In this document, we introduce a PIM-MPLS inter-working framework
which provides the following to resolve the current issues:
a) Complete the full support of PIM features with only PIM and a
point-to-multipoint(P2MP) tunneling protocol involved;
b) Neutrally support various tunnel signaling protocols,
including [mRSVP-TE] and [mLDP]; PIM states are "in-band"
signaled by the tunnel signaling protocol to another PIM site
while the signaling protocol itself uses the data to set up
the tunnel with optimal routing and traffic engineering;
c) Minimize the changes to the two(2) involved protocols and any
introduction of new procedures;
d) Provide flexible tunnel aggregation and load balancing for
scalability and shared resource usage in backbone
e) Minimize overheads in the backbone and on the PIM-MPLS border
routers without introducing performance and scalability
bottlenecks. There is no PIM adjacencies cross over the
backbone network
It is important to point out that some existing solutions can be made
to work with this framework to have complete PIM support.
[mRSVP-TE] and [mLDP] are protocols to signal point-to-
multipoint(P2MP) and multipoint to multipoint(MP2MP) tunnels in an
MPLS network, starting from the leaves of these tunnels. The leaf-
B. Tao et al. Expires April 2, 2014 [Page 5]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
driven signaling is in the same direction as PIM builds its multicast
forwarding information base, i.e., from the multicast data listeners
to the senders. This framework will take advantage of this
characteristics to set up the forwarding states in an MPLS backbone
with less messages and delays.
1.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. An Overview: PIM MPLS Inter-working
2.1 PIM-SM, PIM-SSM and PIM-BiDir States
[PIM] defines four(4) types of Multicast Routing Information
Base(MRIB) entries:
1. (*, *, RP)
2. (*, G)
3. (S, G)
4. (S, G, rpt)
For each MRIB entry, the framework identifies the following PIM
forwarding states for our purpose in this document:
Downstream Per-interface Join/Prune state:
One of {"NoInfo" (NI), "Join" (J)}
Upstream non-interface specific Join/Prune state:
One of {"NotJoined", "Joined"}
For each (*, G), there is a sub-set of states called (S, G, RPT), one
for each (S, G) pair. In this draft, we are only concerned with their
following states:
B. Tao et al. Expires April 2, 2014 [Page 6]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
Downstream Per-interface Join/Prune state:
One of {"NoInfo", "Pruned"}
Upstream non-interface specific Join/Prune State:
One of {"RPTNotJoined(G)", "NotPruned(S,G,rpt)",
"Pruned(S,G,rpt)"}
For definitions of these states, readers are referred to the [PIM]
document.
This framework makes these PIM states as part of signaling data for a
leaf-driven MPLS protocol to signal its P2MP tunnels to achieve
optimal multicast routing within the MPLS network and in highly
scalable fashion. On the other hand, the remote PIM site at upstream
obtains these states from the MPLS signaling data to set up proper
PIM forwarding states for the upstream site. These PIM states are
therefore "In-Band" signaled to the remote PIM site by MPLS, while
MPLS itself sets up optimized multicast LSPs for the traffic to go
through the MPLS backbone.
We hereafter call them M-Flow Specs, and for in-band signaling
purpose, assign a value to each of the types as the following:
M-Flow Spec Type-1(value 1) for (*, *, RP);
M-Flow Spec Type-2(value 2) for (*, G);
M-Flow Spec Type-3(value 3) for (S, G);
M-Flow Spec Type-4(value 4) for (S, G, RPT);
2.2 PIM-MPLS Border Router(mPMBR)
An mPMBR is a border router where PIM meets the MPLS backbone and
inter-works with an MPLS signaling protocol to set up the tunnels,
and where IP multicast packets exit an upstream PIM site to enter the
MPLS backbone or exit the MPLS backbone to enter a downstream PIM
site. An mPMBR can run a multicast member discovery protocol such as
IGMP or MLD, besides PIM. Therefore the mPMBR can have local
listeners.
An mPMBR is called local to a PIM site if it is where the PIM site
connects to the MPLS backbone.
B. Tao et al. Expires April 2, 2014 [Page 7]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
For convenience in the following discussions, we define the following
macro to determine where a P2MP tunnel ingress, or root, will be, for
each M-Flow spec F defined previously:
mPMBR_lkup(F) = {
RP's local mPMBR address, if F is a (*, *, RP) spec; or
RP(G)'s local mPMBR adderss if F is a (*, G) spec; or
S's local mPMBR address if F is a (S, G) spec; or
RP(G)'s local mPMBR if F is a (S, G, RPT)
}
An mPMBR needs to specify its router ID and advertise it to unicast
routing protocol(s) to make the address reachable from all other
mPMBRs. It also specifies its PIM interfaces that face a PIM site, as
well as one or more MPLS interfaces over which P2MP tunnels can be
signaled to support the inter-working functions as defined in this
work. In this framework, P2MP tunnels and their sub-LSPs are
dynamically created and removed when M-Flow specs are created or
removed on mPMBRs.
When a tunnel is created for an M-Flow spec, a logic interface is
also created at the tunnel's ingress and egress endpoints,
respectively. This logic interface will act as if it were a PIM
interface but it does not actually run PIM on it. At an P2MP egress
mPMBR, PIM builds non-interface upstream states on it using the M-
Flow spec created by PIM; at the ingress, or P2MP root mPMBR, PIM
builds per-interface downstream states using the M-Flow spec data
signaled by the tunnel signaling protocol.
An M-FLow spec is said to be "bound" to such a logic interface once
the interface is created as above to pass the traffic which will be
forwarded per the M-Flow spec by the IP multicast forwarding plane.
At a P2MP tunnel's ingress mPMBR, IP multicast packets of the bound
M-FLow spec enters this logic interface, which "leads" the packets
into the MPLS tunnel. At an egress mPMBR, the packets exit the tunnel
and were treated as if they were received from the logic interface as
an upstream interface. At this point the packets will be forwarded
using the native IP multicast forwarding rules.
We call each of these logic interfaces a Quasi-PIM interface(QPI).
2.3 A Reference Model for PIM-MPLS Inter-working(PMIW)
Figure 1 illustrates the PIM-MPLS inter-working model on an mPMBR. In
this model, a QPI is created for an MPLS tunnel at the ingress and
B. Tao et al. Expires April 2, 2014 [Page 8]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
egress LSRs, and this QPI is "advertised" to the mPMBR's PIM, so that
PIM uses it as if it were a PIM interface except that PIM protocol
does not actually run on it, and therefore PIM does not send or
receive any PIM protocol control messages over it (i.e. there is no
PIM adjacency on a QPI), but can still send and receive IP multicast
data packets.
The PIM on each mPMBR uses native PIM procedures to work with its PIM
site router(s) and build proper PIM control and multicast packet
forwarding states over the PIM interfaces as well QPIs.
In order for the mPMBR PIM to build proper control and forwarding
states for a QPI, PIM procedures must be modified to
i) Extend any validation checks to include the QPI to accept
IP multicast packets from the backbone;
ii) PIM RFP_Interface() macro can return a QPI if the RPF
next-hop goes over an IP interface that has MPLS enabled
to support the inter-working.
<---------PIM------>|<---PMIW--->|<----MPLS---->
| |
+--------------------------+
+-----+ | PIM | | |
---| PIM |----| |------------| ========
.......................M-Flows...................
---| |----| |------------| ========
+-----+ ^ |MFIB | ^ | | ^
^ | +-----+--------|---|-------+ |
| | ^ | |
| | | | |
PIM Site | | | |
Router | | QPI MPLS Tunnel
| |
Native PIM mPMBR
Interface
Figure 1: mPMBR PIM-MPLS Inter-working(PMIW) Reference Model
In the Figure 1, an IP multicast packet in mPMBR's PIM segment is
forwarded over the PIM interface(s) as well as QPIs using PIM's
B. Tao et al. Expires April 2, 2014 [Page 9]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
native forwarding rules; when an IP multicast packet enters a QPI,
the packet will be encapsulated with MPLS and enters the
corresponding tunnel. When a packet exits the tunnel at the remote
mPMBR, the QPI on this receiving mPMBR becomes the incoming interface
for the packet, and the packet enters PIM's segment where it will be
forwarded under PIM's native rules.
2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding
When a P2MP tunnel is created in the MPLS backbone for an M-Flow
spec, a QPI is also created as an IP multicast logical interface at
each of the egress and ingress mPMBRs, and the M-Flow spec is bound
to the QPIs at each of the mPMBRs respectively. At the ingress mPMBR,
the QPI is where an IP multicast packet enters the P2MP tunnel with
the MPLS header, and is subsequently forwarded along the tunnel. At
each egress mPMBR, the QPI associated with the tunnel is where the
MPLS packet is de-capsulated, and the resulted IP multicast packet
continues to be forwarded using PIM's native forwarding rules.
The QPI operational status is the same as the P2MP tunnel operational
state.
At an ingress mPMBR, an M-Flow spec F is said to be "bound" to a QPI
(therefore the tunnel as well) when the ingress mPMBR sets the IP
multicast forwarding rules of F to use the QPI as a downstream
interface in order to carry the traffic of F to other PIM sites, via
the backbone network.
At an egress mPMBR, an M-Flow spec F is said to be "bound" to a QPI
(therefore the tunnel as well) when the egress mPMBR sets the IP
multicast forwarding rules of F to use the QPI as an upstream
interface in order to receive the traffic of F from another PIM site,
via the backbone network.
2.3.2 PIM Support for QPI and M-Flow Spec Binding
In this framework, QPIs are made to PIM as if they were a PIM
interface, except that PIM control messages do not go over the QPIs.
The implementation needs to establish proper PIM per-interface
downstream states and upstream states for the QPI and the data
signaled by MPLS, which is originated from other PIM interface states
and the MPLS signaled data from the remote PIM sites.
The actual implementation of the binding on each mPMBR is beyond the
scope of this work.
The detailed PIM protocol support for the QPI will be completed in a
B. Tao et al. Expires April 2, 2014 [Page 10]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
later version.
2.3.3 M-Flow Spec Binding Policies
This framework introduces two sets of policies to restrict the
binding of an M-Flow to a Tunnel.
1. Default Policy: AGG_POLICY_0 (value: 0)
a. One tunnel per (S, G) M-Flow spec; and
b. One tunnel per RP for (*, *, RP) M-Flow spec; and
c. One tunnel for all M-Flow specs of (*, G) such that
RP(G) gives the same RP
The default policy is used by a LSR when no other policy is
explicitly specified. It is the finest grained, and MUST be provided
by an implementation.
2. AGG_POLICY_1 (value: 1):
a. A separate P-Tunnel is used to aggregate all (S, G)
M-Flow specs such that mPMBR_lkup((S,G)) gives the
same mPMBR; and
b. A separate P-Tunnel is used to aggregate all
(*, *, RP) M-Flow specs such that mPMBR_lkup((*, *,RP))
gives the same mPMBR; and
c. A separate P-Tunnel is used to aggregate all (*, G)
M-Flow specs such that mPMBR_lkup((*, G)) gives the same
mPMBR.
AGG_POLICY_1 is the most coarse grained and it, besides others, can
be optionally provided by an implementation.
2.3.4 IP Multicast Packet Forwarding at an mPMBR
If an IP multicast packet arrives at an mPMBR from a PIM interface,
it is forwarded using native IP multicast rules. If an oif is a QPI,
the QPI makes the packet to be forwarded into the corresponding MPLS
P2MP tunnel.
If an IP multicast packet arrives at an egress mPMBR from a P2MP
tunnel, it is handled by the bound QPI, which acts as an iif for IP
multicast flow. If there is no bound QPI, the packet is dropped.
2.4 Impacted PIM messages and procedures
2.4.1 PIM Hello and Adjacency Over MPLS Backbone
An mPMBR does not build any PIM adjacency with any other mPMBR over
B. Tao et al. Expires April 2, 2014 [Page 11]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
the MPLS backbone. Instead, relevant PIM states are mapped to and
from the MPLS signaling data. The details will be covered in later
sections when actual procedures are provided. The PIM downstream per-
interface states on a QPI is directly mapped from the corresponding
MPLS P2MP tunnel's in-band signaled M-Flow spec data. The PIM
upstream states, on the other hand, will be in-band signed to other
PIM sites by a P2MP tunneling protocol, and at the same time the
signaling protocol sets up optimally routed P2MP tunnel within the
MPLS for the multicast flows.
There are no impacts to other routers within MPLS backbone or in PIM
sites.
2.4.2 PIM Assert and Message An implementation following this framework
will not need to make any changes to for PIM asserts, as they will be
only applicable inside a PIM site locally, and the framework does not
let PIM go cross the backbone.
There are no impacts to any router in MPLS backbone or in PIM sites.
2.4.3 PIM hop-by-hop Bootstrapping and Message
A designated multicast channel within MPLS backbone, called Multicast
Bootstrap Tunnel(MBT), is used to carry PIM's bootstrap messages
among all mPMBRs. This tunnel can be either an MP2MP or a bi-
directional P2MP tree. The root is designated by the MPLS network
operator and leaves are all mPMBRs. An MPLS packet entered into the
MBT from any mPMBR will reach all other mPMBRs.
At each mPMBR, PIM sends and receives bootstrap messages to each of
the mPMBR's PIM interfaces as well as the MBT. Each mPMBRs must
implement the functions to send and receive PIM bootstrap messages
over the MBT.
There are no other impacts to an mPMBR PIM's native bootstrap
procedures, and there are no impacts to other routers other than the
mPMBRs.
2.4.4 PIM Unicast Messages and C-RP Advertisement
PIM unicast messages, including CRP advertisement, Register and
RegisterStop, are sent and received in raw IP, with PIM protocol
number.
Each mPMBR must be able to receive a raw IP PIM packet arrived at a
non-PIM interface that is MPLS enabled to support PIM-MPLS inter-
working.
B. Tao et al. Expires April 2, 2014 [Page 12]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
There are no other impacts to PIM's native procedures for unicast
messages on an mPMBR, and there are no impacts to other routers other
than mPMBRs.
2.4.5 PIM RP Register and RegisterStop
Except for the changes common to PIM unicast messages as in the
previous subsection, there are no other impacts for PIM RP register
and registerStop.
For information purpose, a RP may choose to send a (S, G) join toward
the source S after an (S, G) register packet is received by the RP,
and the resulted tree may go over the MPLS network. In this case, the
mechanism and procedures for (S, G) SPT support apply. The details
will be in later subsections.
2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS
An mPMBR, say mpmbr, can have four(4) types of M-Flow specs
corresponding to PIM's upstream states. Except for the M-Flow spec
Type-4, each of the rest, say, F at the mpmbr can bind to an MPLS
P2MP tunnel in the MPLS network with mpmbr as one of its leaf(egress)
LSRs, and the root set to mPMBR_lkup(F). A signaling protocol which
is to work under this framework will support the binding of the Type-
1, Type-2, and Type-3 M-Flow specs with its tunnels. A Type-4 M-FLow
spec is associated with a Type-2 M-Flow spec, as an (S, G, RPT) state
is embedded into a (*, G) state. Therefore there is no separate
binding for a Type-4 M-Flow spec.
Before an M-Flow spec F is bound to a tunnel, the to-be bound tunnel
may have some undetermined information such as a tunnel identifier,
but the tunnel signaling procedure uses F and other known tunnel
identification data during the tunnel signaling. After the M-Flow
spec is bound to a tunnel, tunnel's identification data will be
completed.
The binding can happen at the leaf, at a transit LSR, or at the root,
according to the binding procedure in "Algorithms and Procedures".
2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel
Two tunnels may be aggregated into a single one, if their M-Flow
B. Tao et al. Expires April 2, 2014 [Page 13]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
specs can be merged to form a super set of M-Flow specs, without
violating each original tunnel's aggregation policy. The policy tests
are performed using the algorithms and procedures as defined in
Section 3.
The merged tunnel can be set up using Make-Before-Break(MBB). They
must have the same root in order to be aggregated. The procedure of
P2MP MBB is beyond the scope of this draft.
3 Algorithms and Procedures
3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It
This section describes the procedure to bind an M-Flow spec to a
tunnel.
First, each M-Flow spec F has an aggregation policy to restrict
aggregating the M-Flow spec into a tunnel. This policy can be
configured explicitly by an operator, or is the default policy if it
is not configured.
An M-Flow spec F has the following attributes:
F.agg_policy: An policy to restrict binding and aggregating
F into a tunnel. This policy can be configured
explicitly by an operator, or is the default
policy if it is not configured.
F.spec_type: One of the spec types.
F.bound_tnl: The MPLS tunnel used by the IP multicasting
data which enters and exits the tunnel per F's
corresponding PIM forwarding rules.
For simplicity purpose, and without implying actual implementations,
the framework uses the following macros and functions on each LER or
LSR:
TS = {all tunnels on a node that supports PIM-MPLS
inter-working};
mflow_specs(T) = {set of M-Flow specs that have bound to
tunnel T}
mflow_spec_type(T) = The type of the M-Flow specs that are
bound to tunnel T
agg_policy_compatible(F, T) = TRUE if and only if
T.agg_policy derives F.agg_policy
B. Tao et al. Expires April 2, 2014 [Page 14]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
agg_policy_compatible(T1, T2) = TRUE if and only if
T1.agg_policy derives T2.agg_policy
bind_candidate(F) {
foreach(T in TS) {
if ((T' = F.bound_tnl) != NULL && T' signaling is
completed)
{
return T';
}
if (F.spec_type == mflow_spec_type(T) &&
agg_policy_compatible(F, T))
{
return T;
}
}
return NULL;
}
mflow_spec_bind(F, LSR) {
if ((T = bind_candidate(F)) != NULL)
{
mflow_specs_merge(T);
F.bound_tnl = T;
}
else if (I_am_leaf(LSR))
{
T = initiate_signal_p2mp_tunnel(F);
mflow_specs(T) = {F};
F.bound_tnl = T;
}
else if (I_am_root(LSR))
{
T = continue_signal_p2mp_tunnel(F);
mflow_specs(T) = {F};
F.bound_tnl = T;
}
else //I am transit LSR
{
T = continue_signal_p2mp_tunnel(F);
mflow_specs(T) = {F};
}
}
init_signal_p2mp_tunnel(F) triggers a P2MP tunnel creation
using the local LER as the leaf, and mPMBR_lkup(F) as the
root.
B. Tao et al. Expires April 2, 2014 [Page 15]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
continue_signal_p2mp_tunnel(F)continues the signaling
procedure for the P2MP tunnel that was initiated for F.
The following defines M-Flow spec merge operation:
mflow_specs_merge(T, F)
{
switch(F.spec_type)
{
case Type-1:
/* mflow_specs(T) is a set of group ranges each with
a list of (S, G, RPT) entries; F must be a group
range with a list of its (S, G, RPT) entries */
mflow_specs(T) = mflow_specs(T) union {F};
break;
case Type-2:
mflow_specs(T).sg_rpt_joins =
mflow_specs(T).sg_rpt_joins union F.sg_rpt_joins;
mflow_specs(T).sg_rpt_prunes =
mflow_specs(T).sg_rpt_prunes intersect
F.sg_rpt_prunes
/* sg_rpt_joins and sg_rpt_prunes are the lists of G's
joined and pruned(S, G, RPT) entries */
break;
case Type-3:
mflow_specs(T) = mflow_specs(T) union {F};
/* mflow_specs(T) is a set of (S, G) entries */
break;
case Type-4:
break; /* (S, G, RPT) entries go with wildcards */
}
}
The actual procedures for initiate_signal_p2mp_tunnel(F) and
continue_signal_p2mp_tunnel(F) are MPLS signaling protocol specific
and will be out of scope for this document.
3.1.1. In-Band Tunnel Signaling at Leaf LER
An M-FLow spec F is instantiated when an mPMBR PIM creates a J/P
upstream state. There are three cases under which F may be bound to a
P2MP tunnel at the leaf LER:
Case 1: F is an M-FLow spec already bound to a tunnel egress.
Therefore the corresponding QPI of the tunnel is used
B. Tao et al. Expires April 2, 2014 [Page 16]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
for F.
Case 2: F is not bound to an existing tunnel yet but F's
binding policy is compatible with an M-Flow spec which
has been bound to a P2MP tunnel. Therefore, F is then
bound to the same tunnel, and its QPI is used for F.
The leaf mPMBR does not initiate a new tunnel.
Case 3: None of Case 1 and Case 2 is true. Then a tunnel with
some unknown identifier is signaled using an extended
MPLS protocol, and F as additional data for in-band
signaling. Binding does not happen at this time.
After the unknown tunnel signaling is completed, an
upstream node, either a transit or the root should have
bound F to the tunnel. In addition, it should have also
determined if the tunnel is a new one or an existing
one which this M-Flow spec is bound with.
In the former case, a new QPI is created for the new
tunnel and bound to F. In the latter case, F is bound
to the QPI of the existing tunnel.
3.1.2. In-Band Tunnel Signaling at Transit LSR
As a transit LSR receives a P2MP tunnel signaling message for M-Flow
spec F, it does the following:
Case 1: bind_candidate(F) gives a candidate tunnel T, and T
is then bound to F. Therefore the LSR becomes a
branching LSR. It does the following:
a. Merge F into T.mflow_specs with
mflow_specs_merge(T, F)
b. The branching LSR MPLS signaling procedure of
specific signaling protocol is then performed
Case 2: Otherwise, it is still an unknown tunnel. It does:
a. Merge F to T.mflow_specs using
mflow_specs_merge(T, F);
b. The non-branching LSR MPLS signaling procedure of
the specific protocol is then performed.
B. Tao et al. Expires April 2, 2014 [Page 17]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
3.1.3. In-Band Tunnel Signaling at Root LER
Assume an M-FLow spec F is received at the root mPMBR from MPLS
backbone.
Case 1: F is an M-FLow spec already bound to a tunnel ingress.
Therefore the corresponding QPI of the tunnel is used
for F.
Case 2: F is not bound to an existing tunnel yet but F's
binding policy is compatible with an M-Flow spec which
has been bound to a P2MP tunnel. Therefore, F can then
be bound to the same tunnel, and its QPI is used for F.
Case 3: Neither Case 1 or Case 2 can bind the M-Flow spec.
a. Determine if a new tunnel or an existing tunnel is
used for the M-Flow spec, based on binding policy
and other requirements; if it is a new
tunnel, complete the rest of tunnel signaling using
the signaling protocol;
b. Create a QPI for the tunnel and bound it to F;
c. The new QPI is added to root mPMBR PIM as an
quosi-PIM oif, and F is mapped to PIM's downstream
state;
d. Complete the rest signaling at root with specific
tunnel signaling procedures
3.1.4. Considerations for Load Balance and Traffic Engineering(TE)
Each LSR including any transit node in the MPLS backbone uses the
combination of aggregation and load-balance policies, as well as
traffic engineering requirements to decide if an existing tunnel
should be shared for an M-Flow spec, and how to route it if the M-
Flow spec is to use a separate tunnel.
For example, a transit LSR may decide to merge a new M-Flow spec into
an existing P2MP tunnel to avoid allocating new network resources it;
or decides to reserve resources initially to be ready for a new
tunnel, but once an upstream LSR decides to use an existing tunnel
for the M-Flow spec, it will release the resources it has reserved
earlier. But if eventually a new tunnel is created, the reserved
resources will be used by the new tunnel.
3.2. Operational Procedures for PIM RPT to SPT switch
B. Tao et al. Expires April 2, 2014 [Page 18]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
This framework uses mPMBR PIM's native RPT to SPT switch to initiate
the corresponding traffic switch from the RPT's P2MP tunnel to the
SPT's P2MP tunnel. At the downstream egress mPMBR, when a (S, G, RPT)
state is created for the bound QPI, the mPMBR's PIM-MPLS inter-
working module adds the corresponding M-Flow spec F of Type-4 to the
tunnel's M-Flow specs, using mflow_specs_merge(T, F). The new M-FLow
spec is then sent to the root mPMBR.
When F is received by the root mPMBR, the native PIM procedure will
be performed at the mPMBR to complete the switch. This procedure
determines if (S, G) traffic should be stopped on the RPT as traffic
now is being received from the SPT.
4. M-Flow Spec Format
PIM passes an M-Flow spec to the MPLS signaling protocol when its
forwarding state changes.
An M-Flow spec is encoded in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type | Reserved | Num groups |policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
B. Tao et al. Expires April 2, 2014 [Page 19]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Encoded-Source address takes the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
An Encoded-Group addresses take the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
"Type": 1, 2, 3, or 4 to indicate M-Flow spec type. "Policy" -
M-Flow spec and tunnel binding/aggregation policy.
Other fields are from [PIM] and must be set according to the
PIM specifications.
The encoding of each M-Flow spec is specified according to its type:
B. Tao et al. Expires April 2, 2014 [Page 20]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
For M-Flow Spec Type-1 (*, *, RP):
The Multicast Group Address 1 gives the group range. It is
encoded as the Multicast Group Address + Mask Length.
A one-entry join or prune source list is used for the group
range and the source address of the entry is set to the RP.
(S, G, RPT) list can be encoded in by adding them in join/
prune source list for individual specific group.
For M-Flow Spec Type-2 (*, G):
The Multicast Group Address 1 gives the group address. It is
encoded as the Multicast Group Address + full mask length.
A source entry in joined or pruned source list is used for the
group and the source address of the entry is set to the RP.
(S, G, RPT) list may be encoded by adding them in join/prune
source list for the specific group.
For M-Flow Spec Type-3 (S, G):
Multicast Group Address + Full Length Mask Length give the
group address G;
Source address is encoded into the source list.
For M-Flow Spec Type-4 (S, G, RPT):
Multicast Group Address + Full Length Mask Length give the
group address G.
Source address is encoded into the source list with 'R' bit
set and 'W' bit cleared. See [PIM-SM]"Source Address" encoding
for definition of these bits.
5 OAM&P
B. Tao et al. Expires April 2, 2014 [Page 21]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
This section is to be completed in future.
B. Tao et al. Expires April 2, 2014 [Page 22]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
6 Security Considerations
There is no additional security requirement for this work.
7 IANA Considerations
There is no IANA impact from the framework.
8 References
8.1 Normative References
[PIM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", RFC 4601, August 2006.
[mRSVP-TE] R., Li, Q. Zhao, and C. Jacquenet, "Receiver-Driven
Multicast Traffic Engineered Label Switched Paths", draft-lzj-mpls-
receiver-driven-multicast-rsvp-te-00 (work in progress), March 2012.
[mLDP] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,"Label
Distribution Protocol Extensions for Point-to- Multipoint and
Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November
2011.
[RFC4875] R. Aggarwal, D. Papadimitriou, 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.2 Informative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC6513] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
RFC 6513, Feb. 2012.
[RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP VPNs",
B. Tao et al. Expires April 2, 2014 [Page 23]
INTERNET DRAFT MPLS PIM Inter-working October 2, 2013
RFC 6514, Feb. 2012.
[RFC6517] T. Morin, B. Niven-Jenkins, Y. Kamite, R. Zhang, N.
Leymann, N. Bitar, "Mandatory Features in a Layer 3 Multicast
BGP/MPLS VPN Solution", RFC 6517, Feb., 2012
[RFC6037] E. Rosen, Y. Cai, and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010.
[I-D.Wijnands-mldp-inband] IJ. Wijnands, Ed., T. Eckert, N. Leymann,
M. Napierala, "Multipoint LDP in-band signaling for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-mldp-in-band-signaling-06, December 1, 2011
[I-D.rekhter-pim-sm-over-mldp] Rekhter, Y., Aggarwal, R., and N.
Leymann, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs",
draft-rekhter-pim-sm-over-mldp-04, August 2010.
[I-D.lin-mrsvp-te-mvpn] L. Han, "Multicast VPN Support by Receiver-
Driven Multicast Extensions to RSVP-TE", draft-hlj-l3vpn-mvpn-mrsvp-
te-00, July 2012
Authors' Addresses
Bisong Tao
2330 Central Expressway
Santa Clara, CA 95050
EMail: roberttao@huawei.com
Others(TBD)
Acknowledgement
The author(s) would like to thank the members of Huawei USA IP/MPLS
Team for their helpful review comments during the work of this draft.
B. Tao et al. Expires April 2, 2014 [Page 24]
