draft-ietf-mpls-mldp-in-band-signaling-03.txt   draft-ietf-mpls-mldp-in-band-signaling-04.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: August 12, 2011 N. Leymann Expires: November 19, 2011 N. Leymann
Deutsche Telekom Deutsche Telekom
M. Napierala M. Napierala
AT&T Labs AT&T Labs
February 8, 2011 May 18, 2011
mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-
Multipoint Label Switched Paths to-Multipoint Label Switched Paths
draft-ietf-mpls-mldp-in-band-signaling-03 draft-ietf-mpls-mldp-in-band-signaling-04
Abstract Abstract
Suppose 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 are message is encoded into mLDP messages. When the mLDP messages reach
received at the border of the next IP domain, the encoded information the border of the next IP domain, the encoded information is used to
is used to generate PIM messages that can be sent through the IP generate PIM messages that can be sent through the IP domain. The
domain. The result is an IP multicast tree consisting of a set of IP result is an IP multicast tree consisting of a set of IP multicast
multicast sub-trees that are spliced together with a multipoint LSP. sub-trees that are spliced together with a multipoint LSP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 19, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 2, line 21 skipping to change at page 2, line 15
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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5
2.1. Transiting Unidirectional IP multicast Shared Trees . . . 5 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6
2.2. Transiting IP multicast source trees . . . . . . . . . . . 5 2.2. Transiting IP multicast source trees . . . . . . . . . . . 7
2.3. Transiting IP multicast bidirectional trees . . . . . . . 6 2.3. Transiting IP multicast bidirectional trees . . . . . . . 7
3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 7 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms
for creating point-to-multipoint (P2MP) and multipoint-to-multipoint for creating point-to-multipoint (P2MP) and multipoint-to-multipoint
MP2MP LSPs. These LSPs are typically used for transporting enduser MP2MP LSPs. These LSPs are typically used for transporting enduser
multicast packets. However, the mLDP specification multicast packets. However, the mLDP specification does not provide
[I-D.ietf-mpls-ldp-p2mp] does not provide any rules for associating any rules for associating particular enduser multicast packets with
particular enduser multicast packets with any particular LSP. Other any particular LSP. Other drafts, like
drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in [I-D.ietf-l3vpn-2547bis-mcast], describe applications in which out-
which out-of-band signaling protocols, such as PIM and BGP, are used of-band signaling protocols, such as PIM and BGP, are used to
to establish the mapping between an LSP and the multicast packets establish the mapping between an LSP and the multicast packets that
that need to be forwarded over the LSP. need to be forwarded over the LSP.
This draft describes an application in which the information needed This draft describes an application in which the information needed
to establish the mapping between an LSP and the set of multicast to establish the mapping between an LSP and the set of multicast
packets to be forwarded over it is carried in the "opaque value" packets to be forwarded over it is carried in the "opaque value"
field of an mLDP FEC element. When an IP multicast tree (either a field of an mLDP FEC element. When an IP multicast tree (either a
source-specific tree or a bidirectional tree) enters the MPLS network source-specific tree or a bidirectional tree) enters the MPLS network
the (S,G) or (*,G) information from the IP multicast control plane the (S,G) or (*,G) information from the IP multicast control plane
state is carried in the opaque value field of the mLDP FEC message. state is carried in the opaque value field of the mLDP FEC message.
As the tree leaves the MPLS network, this information is extracted As the tree leaves the MPLS network, this information is extracted
from the FEC element and used to build the IP multicast control from the FEC element and used to build the IP multicast control
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 an source IP address and/or IP multicast destination address, also
refered to as (S,G) and (*,G). refered to as (S,G) and (*,G).
mLDP : Multicast LDP. RP: The PIM Rendezvous Point.
SSM: PIM Source Specific Multicast.
ASM: PIM Any Source Multicast.
mLDP : Multipoint LDP.
Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the Transit LSP : An 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
skipping to change at page 5, line 34 skipping to change at page 5, line 40
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 Suppose an LSR, call it D, is attached to a network that is capable
of MPLS multicast and IP multicast, and D has the desire to create IP of MPLS multicast and IP multicast, and D is required to create a IP
multicast tree due to a certain IP multicast event, like a PIM Join, multicast tree due to a certain IP multicast event, like a PIM Join,
MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto- MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery. discovery route [I-D.rekhter-pim-sm-over-mldp] or Rendezvous Point
Suppose that D can determine that the IP multicast tree needs to (RP) discovery. Suppose that D can determine that the IP multicast
travel through the MPLS network until it reaches some other LSR, U. tree needs to travel through the MPLS network until it reaches some
For instance, when D looks up the route to the Source or Rendezvous other LSR, U. For instance, when D looks up the route to the Source
Point (RP) [RFC4601] of the IP multicast tree, it may discover that or RP [RFC4601] of the IP multicast tree, it may discover that the
the route is a BGP route with U as the BGP next hop. Then D may route is a BGP route with U as the BGP next hop. Then D may chose to
chose to set up a P2MP or MP2MP LSP, with U as root, and to make that set up a P2MP or MP2MP LSP, with U as root, and to make that LSP
LSP become part of the IP multicast distribution tree. Note that become part of the IP multicast distribution tree. Note that other
other methods are possible to determine that an IP multicast tree is methods are possible to determine that an IP multicast tree is to be
to be transported across an MPLS network using P2MP or MP2MP LSPs, transported across an MPLS network using P2MP or MP2MP LSPs, these
these methods are outside the scope of this document. methods are outside the scope of this document.
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 transport the multicast tree via a P2MP or MP2MP LSP In order to establish a multicast tree via a P2MP or MP2MP LSP using
using in-band signaling the source and the group will be encoded into in-band signaling the source and the group will be encoded into an
an mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of 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) encoding depends on the IP version. The tree type (P2MP or MP2MP)
depends on whether this is a source specific or a bidirectional 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 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 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 information a mLDP FEC is created and the LSP is build towards the
root of the LSP. root of the LSP.
When an LSR receives a label mapping or withdraw and discovers it is 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 the root of the identified P2MP or MP2MP LSP, then the following
procedure is executed. If the opaque encoding of the FEC indicates procedure is executed. If the opaque encoding of the FEC indicates
this is a Transit LSP (indicated by the opaque type), the opaque TLV 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 is decoded and the multicast source and group is passed to the
multicast code. If the multicast tree information is received via a multicast code. If the multicast tree information is received via a
label mapping, the multicast code will adds the downstream LDP label mapping, the multicast code will add the downstream LDP
neighbor to the olist of the corresponding (S,G) or (*,G) state, 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 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 label withdraw, the multicast code will remove the downstream LDP
neighbor from the olist of the corresponding (S,G) or (*,G) state. neighbor from the olist of the corresponding (S,G) or (*,G) state.
From this point on normal PIM processing will occur. 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
skipping to change at page 7, line 5 skipping to change at page 7, line 14
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 draft.
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 transporting 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
sources. One possible means is the use of MSDP [RFC3618]. Another sources. One possible means is the use of MSDP [RFC3618]. Another
possible means is to use BGP Source Active auto-discovery routes, as possible means is to use BGP Source Active auto-discovery routes, as
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
skipping to change at page 7, line 29 skipping to change at page 7, line 38
Bidirectional IP multicast trees [RFC5015] MUST be transported across Bidirectional IP multicast trees [RFC5015] MUST be transported across
a MPLS network using MP2MP LSPs. A bidirectional tree does not have a MPLS network using MP2MP LSPs. A bidirectional tree does not have
a specific source address; the group address, subnet mask and RP are a specific source address; the group address, subnet mask and RP are
relevant for multicast forwarding. This document does not provide relevant for multicast forwarding. This document does not provide
procedures to discover RP to group mappings dynamically across an procedures to discover RP to group mappings dynamically across an
MPLS network and assumes the RP is statically defined. Support of MPLS network and assumes the RP is statically defined. Support of
dynamic RP mappings in combination with in-band signaling is outside dynamic RP mappings in combination with in-band signaling is outside
the scope of his document. the scope of his document.
The RP for the group is used to select the ingress PE and root of the The RP for the group is used to select the ingress LSR and root of
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 RPA state. The first multicast, the group specific state and the RP state. The first type
type is typically created due to receiving a PIM join and has a is typically created due to receiving a PIM join and has a subnet
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.
The RPA state is used to build a tree to the RP and used for sender The RP state is used to build a tree to the RP and used for sender
only branches. Each state (group specific and RPA state) will result only branches. Each state (group specific and RP state) will result
in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be
done by PIM on the root LSR. No speccial procedures are nessesary done by PIM on the root LSR. No speccial procedures are nessesary
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.
In order transport the packets of sender only branch to the root of In order transport the packets of sender only branch to the root of
the LSP a MP2MP is created. This will cause the sender only branches the LSP a MP2MP is created. This will cause the sender only branches
to receive each others packets. These packets will be dropped and to receive each others packets. These packets will be dropped and
not forwarded, if that affect is undesireable some other means of not forwarded, 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
skipping to change at page 8, line 26 skipping to change at page 8, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source | Type | Length | Source
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group | Group
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 (to be assigned by IANA). Type: 3 (to be assigned by IANA).
Length: 8 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.
3.2. Transit IPv6 Source TLV 3.2. Transit IPv6 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 7 skipping to change at page 9, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source ~ | Type | Length | Source ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~ ~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4 (to be assigned by IANA). Type: 4 (to be assigned by IANA).
Length: 32 Length: 32 octets
Source: IPv6 multicast source address, 16 octets. Source: IPv6 multicast source address, 16 octets.
Group: IPv6 multicast group address, 16 octets. Group: IPv6 multicast group address, 16 octets.
3.3. Transit IPv4 bidir TLV 3.3. Transit IPv4 bidir 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 | Mask Len | | Type | Length | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP | | RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group | | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5 (to be assigned by IANA). Type: 5 (to be assigned by IANA).
Length: 9 Length: 9 octets
Mask Len: The number of contiguous one bits that are left justified Mask Len: The number of contiguous one bits that are left justified
and used as a mask, 1 octet. and used as a mask, 1 octet.
RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4 RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4
octets. octets.
Group: IPv4 multicast group address, 4 octets. Group: IPv4 multicast group address, 4 octets.
3.4. Transit IPv6 bidir TLV 3.4. Transit IPv6 bidir TLV
skipping to change at page 10, line 20 skipping to change at page 10, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 (to be assigned by IANA). Type: 6 (to be assigned by IANA).
Length: 33 Length: 33 octets
Mask Len: The number of contiguous one bits that are left justified Mask Len: The number of contiguous one bits that are left justified
and used as a mask, 1 octet. and used as a mask, 1 octet.
RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16
octets. octets.
Group: IPv6 multicast group address, 16 octets. Group: IPv6 multicast group address, 16 octets.
4. Security Considerations 4. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, as described in [RFC5036]. specification, as described in [RFC5036].
5. IANA considerations 5. IANA considerations
This document requires allocation from the LDP MP Opaque Value This document requires allocation from the 'LDP MP Opaque Value
Element type name space managed by IANA. The values requested are: Element basic type' name space managed by IANA. The values requested
are:
Transit IPv4 Source TLV type - requested 3 Transit IPv4 Source TLV type - 3
Transit IPv6 Source TLV type - requested 4 Transit IPv6 Source TLV type - 4
Transit IPv4 Bidir TLV type - requested 5
Transit IPv6 Bidir TLV type - requested 6 Transit IPv4 Bidir TLV type - 5
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 draft. Also
thanks to Yakov Rekhter, Adrial Farrel and Uwe Joorde for providing thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde and Loa Andersson
comments on this draft. for providing comments on this draft.
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
 End of changes. 31 change blocks. 
89 lines changed or deleted 89 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/