draft-ietf-mpls-mldp-in-band-signaling-07.txt   draft-ietf-mpls-mldp-in-band-signaling-08.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: April 25, 2013 N. Leymann Expires: June 2, 2013 N. Leymann
Deutsche Telekom Deutsche Telekom
M. Napierala M. Napierala
AT&T Labs AT&T Labs
October 22, 2012 November 29, 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-07 draft-ietf-mpls-mldp-in-band-signaling-08
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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 April 25, 2013. This Internet-Draft will expire on June 2, 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting Unidirectional IP multicast Shared Trees . . . 7 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6
2.2. Transiting IP multicast source trees . . . . . . . . . . . 7 2.2. Transiting IP multicast source trees . . . . . . . . . . . 6
2.3. Transiting IP multicast bidirectional trees . . . . . . . 8 2.3. Transiting IP multicast bidirectional trees . . . . . . . 7
3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 8 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 9 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 10 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 12 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The mLDP (Multipoint LDP) [RFC6388] specification describes The mLDP (Multipoint LDP) [RFC6388] specification describes
mechanisms for creating point-to-multipoint (P2MP) and multipoint-to- mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are
typically used for transporting end-user multicast packets. However, typically used for transporting end-user multicast packets. However,
the mLDP specification does not provide any rules for associating the mLDP specification does not provide any rules for associating
particular end-user multicast packets with any particular LSP. Other particular end-user multicast packets with any particular LSP. Other
documents, like [RFC6513], describe applications in which out-of-band documents, like [RFC6513], describe applications in which out-of-band
skipping to change at page 5, line 18 skipping to change at page 4, line 18
ASM: PIM Any Source Multicast. ASM: PIM Any Source Multicast.
mLDP : Multipoint LDP. mLDP : Multipoint LDP.
Transit LSP : A 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) identifying 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 that may each MP2MP LSP: An LSP that connects a set of leaf nodes that may each
independently act 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.
skipping to change at page 6, line 35 skipping to change at page 5, line 35
LSP become part of the IP multicast distribution tree. Note that LSP become part of the IP multicast distribution tree. Note that
other methods are possible to determine that an IP multicast tree is other methods are possible to determine that an IP multicast tree is
to be transported across an MPLS network using P2MP or MP2MP LSPs, to be transported across an MPLS network using P2MP or MP2MP LSPs,
these methods are outside the scope of this document. these methods are outside the scope of this document.
In order to establish a multicast tree via a P2MP or MP2MP LSP using 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 "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 the IP address of LSR U as the "Root Node Address", and with the
source and the group encoded into the "opaque value" ([RFC6388], source and the group encoded into the "opaque value" ([RFC6388],
section 2.2 and 3.2). Several different opaque value types are 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 defined in this document; LSR D MUST NOT use a particular opaque
type unless it knows (through provisioning, or through some other value type unless it knows (through provisioning, or through some
means outside the scope of this document) that LSR U supports the other means outside the scope of this document) that LSR U supports
root node procedures for that opaque value type. the root node procedures for that opaque value type.
The particular type of FEC Element and opaque value used depends on The particular type of FEC Element and opaque value used depends on
the IP address family being used, and on whether the multicast tree the IP address family being used, and on whether the multicast tree
being established is a source specific or a bidirectional multicast being established is a source specific or a bidirectional multicast
tree. tree.
When an LSR receives a label mapping or withdraw whose FEC Element When an LSR receives a label mapping or withdraw whose FEC Element
contains one of the opaque value types defined in this document, and 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 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. of that FEC element, the LSR follows the procedures of RFC 6388.
skipping to change at page 8, line 29 skipping to change at page 7, line 29
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.
The RP 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 RP 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 special procedures are necessary for
for PIM to merge the two LSPs, each LSP is effectively treated as a PIM to merge the two LSPs, each LSP is effectively treated as a PIM
PIM enabled interface. Please see [RFC5015] for more details. 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. [I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1.
skipping to change at page 9, line 16 skipping to change at page 8, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (octet size of Source and Group fields)
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4 (to be assigned by IANA). Type: 4 (to be assigned by IANA).
Length: 32 octets Length: 32 (octet size of Source and Group fields)
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 octets Length: 9 (octet size of Mask Len, RP and Group fields)
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. Maximum value allowed is 32.
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
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
skipping to change at page 11, line 9 skipping to change at page 10, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6 (to be assigned by IANA). Type: 6 (to be assigned by IANA).
Length: 33 octets Length: 33 (octet size of Mask Len, RP and Group fields)
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. Maximum value allowed is 128.
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].
skipping to change at page 11, line 41 skipping to change at page 10, line 41
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 document. Thanks to Eric Rosen for his valuable comments on this document.
Also thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde, Loa Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
Andersson and Arkadiy Gulko for providing comments on this document. 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
 End of changes. 16 change blocks. 
51 lines changed or deleted 39 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/