draft-ietf-mpls-mldp-in-band-signaling-06.txt   draft-ietf-mpls-mldp-in-band-signaling-07.txt 
Network Working Group IJ. Wijnands, Ed. Network Working Group IJ. Wijnands, Ed.
Internet-Draft T. Eckert Internet-Draft T. Eckert
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: December 24, 2012 N. Leymann Expires: April 25, 2013 N. Leymann
Deutsche Telekom Deutsche Telekom
M. Napierala M. Napierala
AT&T Labs AT&T Labs
June 22, 2012 October 22, 2012
Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-
to-Multipoint Label Switched Paths to-Multipoint Label Switched Paths
draft-ietf-mpls-mldp-in-band-signaling-06 draft-ietf-mpls-mldp-in-band-signaling-07
Abstract Abstract
Consider an IP multicast tree, constructed by Protocol Independent Consider an IP multicast tree, constructed by Protocol Independent
Multicast (PIM), needs to pass through an MPLS domain in which Multicast (PIM), needs to pass through an MPLS domain in which
Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
Multipoint Labels Switched Paths (LSPs) can be created. The part of Multipoint Labels Switched Paths (LSPs) can be created. The part of
the IP multicast tree that traverses the MPLS domain can be the IP multicast tree that traverses the MPLS domain can be
instantiated as a multipoint LSP. When a PIM Join message is instantiated as a multipoint LSP. When a PIM Join message is
received at the border of the MPLS domain, information from that received at the border of the MPLS domain, information from that
message is encoded into mLDP messages. When the mLDP messages reach message is encoded into mLDP messages. When the mLDP messages reach
the border of the next IP domain, the encoded information is used to the border of the next IP domain, the encoded information is used to
generate PIM messages that can be sent through the IP domain. The generate PIM messages that can be sent through the IP domain. The
result is an IP multicast tree consisting of a set of IP multicast result is an IP multicast tree consisting of a set of IP multicast
sub-trees that are spliced together with a multipoint LSP. sub-trees that are spliced together with a multipoint LSP. This
document describes procedures how IP multicast trees are spliced
together with multipoint LSPs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 24, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5
2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 7
2.2. Transiting IP multicast source trees . . . . . . . . . . . 7 2.2. Transiting IP multicast source trees . . . . . . . . . . . 7
2.3. Transiting IP multicast bidirectional trees . . . . . . . 7 2.3. Transiting IP multicast bidirectional trees . . . . . . . 8
3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 8 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 9
3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 10
3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms The mLDP (Multipoint LDP) [RFC6388] specification describes
for creating point-to-multipoint (P2MP) and multipoint-to-multipoint mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
MP2MP LSPs. These LSPs are typically used for transporting enduser multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are
multicast packets. However, the mLDP specification does not provide typically used for transporting end-user multicast packets. However,
any rules for associating particular enduser multicast packets with the mLDP specification does not provide any rules for associating
any particular LSP. Other drafts, like particular end-user multicast packets with any particular LSP. Other
[I-D.ietf-l3vpn-2547bis-mcast], describe applications in which out- documents, like [RFC6513], describe applications in which out-of-band
of-band signaling protocols, such as PIM and BGP, are used to signaling protocols, such as PIM and BGP, are used to establish the
establish the mapping between an LSP and the multicast packets that mapping between an LSP and the multicast packets that need to be
need to be forwarded over the LSP. forwarded over the LSP.
This draft describes an application in which the information needed This document describes an application in which the information
to establish the mapping between an LSP and the set of multicast needed to establish the mapping between an LSP and the set of
packets to be forwarded over it is carried in the "opaque value" multicast packets to be forwarded over it is carried in the "opaque
field of an mLDP FEC element. When an IP multicast tree (either a value" field of an mLDP FEC (Forwarding Equivalence Class) element.
source-specific tree or a bidirectional tree) enters the MPLS network When an IP multicast tree (either a source-specific tree or a
the (S,G) or (*,G) information from the IP multicast control plane bidirectional tree) enters the MPLS network the (S,G) or (*,G)
state is carried in the opaque value field of the mLDP FEC message. information from the IP multicast control plane state is carried in
As the tree leaves the MPLS network, this information is extracted the opaque value field of the mLDP FEC message. As the tree leaves
from the FEC element and used to build the IP multicast control the MPLS network, this information is extracted from the FEC element
plane. PIM messages can be sent outside the MPLS domain. Note that and used to build the IP multicast control plane. PIM messages can
although the PIM control messages are sent periodically, the mLDP be sent outside the MPLS domain. Note that although the PIM control
messages are not. messages are sent periodically, the mLDP messages are not.
Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
the MPLS network. This type of service works well if the number of the MPLS network. A network operator should expect to see as many
LSPs that are created is under control of the MPLS network operator, LSPs in the MPLS network as there are IP multicast trees. A network
or if the number of LSPs for a particular service are known to be operator should be aware how IP multicast state is created in the
limited in number. network to ensure it does not exceed the scalability numbers of the
protocol, either PIM or mLDP.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
IP multicast tree : An IP multicast distribution tree identified by IP multicast tree : An IP multicast distribution tree identified by
an source IP address and/or IP multicast destination address, also a IP multicast Group address and optionally a Source IP address,
refered to as (S,G) and (*,G). also referred to as (S,G) and (*,G).
RP: The PIM Rendezvous Point. RP: The PIM Rendezvous Point.
SSM: PIM Source Specific Multicast. SSM: PIM Source Specific Multicast.
ASM: PIM Any Source Multicast. ASM: PIM Any Source Multicast.
mLDP : Multipoint LDP. mLDP : Multipoint LDP.
Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the Transit LSP : A P2MP or MP2MP LSP whose FEC element contains the
(S,G) or (*,G) identifying a particular IP multicast distribution (S,G) or (*,G) identifying a particular IP multicast distribution
tree. tree.
In-band signaling : Using the opaque value of a mLDP FEC element to In-band signaling : Using the opaque value of a mLDP FEC element to
carry the (S,G) or (*,G) indentifying a particular IP multicast carry the (S,G) or (*,G) indentifying a particular IP multicast
tree. tree.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs. LSRs.
MP2MP LSP: An LSP that connects a set of leaf nodes, acting MP2MP LSP: An LSP that connects a set of leaf nodes that may each
indifferently as ingress or egress. independently act as ingress or egress.
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
Ingress LSR: Source of the P2MP LSP, also referred to as root node. Ingress LSR: Source of the P2MP LSP, also referred to as root node.
Egress LSR: One of potentially many destinations of an LSP, also Egress LSR: One of potentially many destinations of an LSP, also
referred to as leaf node in the case of P2MP and MP2MP LSPs. referred to as leaf node in the case of P2MP and MP2MP LSPs.
Transit LSR: An LSR that has one or more directly connected Transit LSR: An LSR that has one or more directly connected
downstream LSRs. downstream LSRs.
2. In-band signaling for MP LSPs 2. In-band signaling for MP LSPs
Suppose an LSR, call it D, is attached to a network that is capable Consider the following topology;
of MPLS multicast and IP multicast, and D is required to create a IP |--- IPM ---|--- MPLS --|--- IPM ---|
multicast tree due to a certain IP multicast event, like a PIM Join,
MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto- S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
discovery route [I-D.rekhter-pim-sm-over-mldp] or Rendezvous Point
(RP) discovery. Suppose that D can determine that the IP multicast Figure 1.
tree needs to travel through the MPLS network until it reaches some
other LSR, U. For instance, when D looks up the route to the Source Nodes A and B are IP Multicast capable routers and respectively
or RP [RFC4601] of the IP multicast tree, it may discover that the connect to a Source/RP and a Receiver. Nodes U, C and D are MPLS
route is a BGP route with U as the BGP next hop. Then D may chose to Label Switched Routers (LSRs).
set up a P2MP or MP2MP LSP, with U as root, and to make that LSP
become part of the IP multicast distribution tree. Note that other Label Switched Router D is attached to a network that is capable of
methods are possible to determine that an IP multicast tree is to be MPLS multicast and IP multicast (see figure 1), and D is required to
transported across an MPLS network using P2MP or MP2MP LSPs, these create a IP multicast tree due to a certain IP multicast event, like
methods are outside the scope of this document. a PIM Join, MSDP Source Announcement (SA) [RFC3618], BGP Source
Active auto-discovery route [I-D.rekhter-pim-sm-over-mldp] or
Rendezvous Point (RP) discovery. Suppose that D can determine that
the IP multicast tree needs to travel through the MPLS network until
it reaches LSR U. For instance, when D looks up the route to the
Source or RP [RFC4601] of the IP multicast tree, it may discover that
the route is a BGP route with U as the BGP next hop. Then D may
chose to set up a P2MP or MP2MP LSP, with U as root, and to make that
LSP become part of the IP multicast distribution tree. Note that
other methods are possible to determine that an IP multicast tree is
to be transported across an MPLS network using P2MP or MP2MP LSPs,
these methods are outside the scope of this document.
In order to establish a multicast tree via a P2MP or MP2MP LSP using
"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with
the IP address of LSR U as the "Root Node Address", and with the
source and the group encoded into the "opaque value" ([RFC6388],
section 2.2 and 3.2). Several different opaque value types are
defined in this document; LSR D MUST NOT use a particlar opaque value
type unless it knows (through provisioning, or through some other
means outside the scope of this document) that LSR U supports the
root node procedures for that opaque value type.
The particular type of FEC Element and opaque value used depends on
the IP address family being used, and on whether the multicast tree
being established is a source specific or a bidirectional multicast
tree.
When an LSR receives a label mapping or withdraw whose FEC Element
contains one of the opaque value types defined in this document, and
that LSR is not the one identified by the "Root Node Address" field
of that FEC element, the LSR follows the procedures of RFC 6388.
When an LSR receives a label mapping or withdraw whose FEC Element
contains one of the opaque value types defined in this document, and
that LSR is the one identified by the "Root Node Address" field of
that FEC element, then the following procedure is executed. The
multicast source and group are extracted and passed to the multicast
code. If a label mapping is being processed, the multicast code will
add the downstream LDP neighbor to the olist of the corresponding
(S,G) or (*,G) state, creating such state if it does not already
exist. If a label withdraw is being processed, the multicast code
will remove the downstream LDP neighbor from the olist of the
corresponding (S,G) or (*,G) state. From this point on normal PIM
processing will occur.
Note that if the LSR identified by the "Root Node Address" field does
not recognize the opaque value type, the MP LSP will be established,
but the root node will not send any multicast data packets on it.
Source or RP addresses that are reachable in a VPN context are Source or RP addresses that are reachable in a VPN context are
outside the scope of this document. outside the scope of this document.
Multicast groups that operate in PIM Dense-Mode are outside the scope Multicast groups that operate in PIM Dense-Mode are outside the scope
of this document. of this document.
In order to establish a multicast tree via a P2MP or MP2MP LSP using
in-band signaling the source and the group will be encoded into an
mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of
encoding depends on the IP version. The tree type (P2MP or MP2MP)
depends on whether this is a source specific or a bidirectional
multicast tree. The root of the tree is the BGP next-hop that was
found during the route lookup on the source or RP. Using this
information a mLDP FEC is created and the LSP is build towards the
root of the LSP.
When an LSR receives a label mapping or withdraw and discovers it is
the root of the identified P2MP or MP2MP LSP, then the following
procedure is executed. If the opaque encoding of the FEC indicates
this is a Transit LSP (indicated by the opaque type), the opaque TLV
is decoded and the multicast source and group is passed to the
multicast code. If the multicast tree information is received via a
label mapping, the multicast code will add the downstream LDP
neighbor to the olist of the corresponding (S,G) or (*,G) state,
creating such state if it does not already exist. If it is due to a
label withdraw, the multicast code will remove the downstream LDP
neighbor from the olist of the corresponding (S,G) or (*,G) state.
From this point on normal PIM processing will occur.
2.1. Transiting Unidirectional IP multicast Shared Trees 2.1. Transiting Unidirectional IP multicast Shared Trees
Nothing prevents PIM shared trees, used by PIM-SM in the ASM service Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
model, from being transported across a MPLS core. However, it is not model, from being transported across a MPLS core. However, it is not
possible to prune individual sources from the shared tree without the possible to prune individual sources from the shared tree without the
use of an additional out-of-band signaling protocol, like PIM or BGP use of an additional out-of-band signaling protocol, like PIM or BGP
[I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared [I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared
Trees across a Transit LSP is outside the scope of this draft. Trees across a Transit LSP is outside the scope of this document.
2.2. Transiting IP multicast source trees 2.2. Transiting IP multicast source trees
IP multicast source trees can either be created via PIM operating in IP multicast source trees can either be created via PIM operating in
SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM
mode, the usual means of discovering active sources is to join a mode, the usual means of discovering active sources is to join a
sparse mode shared tree. However, this document does not provide any sparse mode shared tree. However, this document does not provide any
method of establishing a sparse mode shared tree across an MPLS method of establishing a sparse mode shared tree across an MPLS
network. To apply the technique of this document to PIM-SM in ASM network. To apply the technique of this document to PIM-SM in ASM
mode, there must be some other means of discovering the active mode, there must be some other means of discovering the active
skipping to change at page 7, line 29 skipping to change at page 8, line 7
documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of
discovering the active sources is outside the scope of this document, discovering the active sources is outside the scope of this document,
and as a result this document does not specify everything that is and as a result this document does not specify everything that is
needed to support the ASM service model using in-band signaling. needed to support the ASM service model using in-band signaling.
The source and group addresses are encoded into the a transit TLV as The source and group addresses are encoded into the a transit TLV as
specified in Section 3.1 and Section 3.2. specified in Section 3.1 and Section 3.2.
2.3. Transiting IP multicast bidirectional trees 2.3. Transiting IP multicast bidirectional trees
Bidirectional IP multicast trees [RFC5015] MUST be transported across If a Bidirectional IP multicast trees [RFC5015] has to be transported
a MPLS network using MP2MP LSPs. A bidirectional tree does not have over a MPLS network using in-band signaling, as described in this
a specific source address; the group address, subnet mask and RP are document, it MUST be transported using a MP2MP LSPs. A bidirectional
relevant for multicast forwarding. This document does not provide tree does not have a specific source address; the group address,
procedures to discover RP to group mappings dynamically across an subnet mask and RP are relevant for multicast forwarding. This
MPLS network and assumes the RP is statically defined. Support of document does not provide procedures to discover RP to group mappings
dynamic RP mappings in combination with in-band signaling is outside dynamically across an MPLS network and assumes the RP is statically
the scope of his document. defined. Support of dynamic RP mappings in combination with in-band
signaling is outside the scope of his document.
The RP for the group is used to select the ingress LSR and root of The RP for the group is used to select the ingress LSR and root of
the LSP. The group address is encoded according to the rules of the LSP. The group address is encoded according to the rules of
Section 3.3 or Section 3.4, depending on the IP version. The subnet Section 3.3 or Section 3.4, depending on the IP version. The subnet
mask associated with the bidirectional group is encoded in the mask associated with the bidirectional group is encoded in the
Transit TLV. There are two types of bidirectional states in IP Transit TLV. There are two types of bidirectional states in IP
multicast, the group specific state and the RP state. The first type multicast, the group specific state and the RP state. The first type
is typically created due to receiving a PIM join and has a subnet is typically created due to receiving a PIM join and has a subnet
mask of 32 for IPv4 and 128 for IPv6. The latter is typically mask of 32 for IPv4 and 128 for IPv6. The latter is typically
created via the static RP mapping and has a variable subnet mask. created via the static RP mapping and has a variable subnet mask.
skipping to change at page 8, line 13 skipping to change at page 8, line 40
for PIM to merge the two LSPs, each LSP is effectively treated as a for PIM to merge the two LSPs, each LSP is effectively treated as a
PIM enabled interface. Please see [RFC5015] for more details. PIM enabled interface. Please see [RFC5015] for more details.
For transporting the packets of a sender only branch we create a For transporting the packets of a sender only branch we create a
MP2MP LSP. Other sender only branches will receive these packets and MP2MP LSP. Other sender only branches will receive these packets and
will not forward them because there are no receivers. These packets will not forward them because there are no receivers. These packets
will be dropped. If that affect is undesireable some other means of will be dropped. If that affect is undesireable some other means of
transport has to be established to forward packets to the root of the transport has to be established to forward packets to the root of the
tree, like a Multi-Point to Point LSP for example. A technique to tree, like a Multi-Point to Point LSP for example. A technique to
unicast packets to the root of a P2MP or MP2MP LSP is documented in unicast packets to the root of a P2MP or MP2MP LSP is documented in
[I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1 and [I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1.
[I-D.ietf-mpls-ldp-p2mp] section 3.
3. LSP opaque encodings 3. LSP opaque encodings
This section documents the different transit opaque encodings. This section documents the different transit opaque encodings.
3.1. Transit IPv4 Source TLV 3.1. Transit IPv4 Source TLV
0 1 2 3 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 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 | Length | Source | Type | Length | Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group | | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 (to be assigned by IANA). Type: 3 (to be assigned by IANA).
Length: 8 octets Length: 8 octets
Source: IPv4 multicast source address, 4 octets. Source: IPv4 multicast source address, 4 octets.
Group: IPv4 multicast group address, 4 octets. Group: IPv4 multicast group address, 4 octets.
skipping to change at page 11, line 21 skipping to change at page 11, line 40
Transit IPv4 Source TLV type - 3 Transit IPv4 Source TLV type - 3
Transit IPv6 Source TLV type - 4 Transit IPv6 Source TLV type - 4
Transit IPv4 Bidir TLV type - 5 Transit IPv4 Bidir TLV type - 5
Transit IPv6 Bidir TLV type - 6 Transit IPv6 Bidir TLV type - 6
6. Acknowledgments 6. Acknowledgments
Thanks to Eric Rosen for his valuable comments on this draft. Also Thanks to Eric Rosen for his valuable comments on this document.
thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde and Loa Andersson Also thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde, Loa
for providing comments on this draft. Andersson and Arkadiy Gulko for providing comments on this document.
7. Contributing authors 7. Contributing authors
Below is a list of the contributing authors in alphabetical order: Below is a list of the contributing authors in alphabetical order:
Toerless Eckert Toerless Eckert
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
USA USA
skipping to change at page 12, line 21 skipping to change at page 12, line 47
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mpls-ldp-p2mp] [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
Minei, I., Wijnands, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-15 (work in progress), Paths", RFC 6388, November 2011.
August 2011.
8.2. Informative References 8.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[I-D.ietf-l3vpn-2547bis-mcast] [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., VPNs", RFC 6513, February 2012.
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
in progress), January 2010.
[I-D.rekhter-pim-sm-over-mldp] [I-D.rekhter-pim-sm-over-mldp]
Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode
Trees over P2MP mLDP LSPs", Trees over P2MP mLDP LSPs",
draft-rekhter-pim-sm-over-mldp-04 (work in progress), draft-rekhter-pim-sm-over-mldp-04 (work in progress),
August 2011. August 2011.
[I-D.rosen-l3vpn-mvpn-mspmsi] [I-D.rosen-l3vpn-mvpn-mspmsi]
Cai, Y., Rosen, E., Wijnands, I., Napierala, M., and A. Cai, Y., Rosen, E., Wijnands, I., Napierala, M., and A.
Boers, "MVPN: Optimized use of PIM via MS-PMSIs", Boers, "MVPN: Optimized use of PIM via MS-PMSIs",
draft-rosen-l3vpn-mvpn-mspmsi-09 (work in progress), draft-rosen-l3vpn-mvpn-mspmsi-10 (work in progress),
August 2011. February 2012.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
 End of changes. 32 change blocks. 
110 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/