draft-ietf-mpls-mldp-in-band-signaling-00.txt | draft-ietf-mpls-mldp-in-band-signaling-01.txt | |||
---|---|---|---|---|
Network Working Group I. Wijnands (Editor) | Network Working Group I. Wijnands (Editor) | |||
Internet-Draft T. Eckert | Internet-Draft T. Eckert | |||
Intended status: Standards Track Cisco Systems, Inc. | Intended status: Standards Track Cisco Systems, Inc. | |||
Expires: July 22, 2010 N. Leymann | Expires: August 30, 2010 N. Leymann | |||
Deutsche Telekom | Deutsche Telekom | |||
M. Napierala | M. Napierala | |||
AT&T Labs | AT&T Labs | |||
January 18, 2010 | February 26, 2010 | |||
mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- | mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- | |||
Multipoint Label Switched Paths | Multipoint Label Switched Paths | |||
draft-ietf-mpls-mldp-in-band-signaling-00 | draft-ietf-mpls-mldp-in-band-signaling-01 | |||
Abstract | ||||
Suppose an IP multicast tree, constructed by Protocol Independent | ||||
Multicast (PIM), needs to pass through an MPLS domain in which | ||||
Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- | ||||
Multipoint Labels Switched Paths (LSPs) can be created. The part of | ||||
the IP multicast tree that traverses the MPLS domain can be | ||||
instantiated as a multipoint LSP. When a PIM Join message is | ||||
received at the border of the MPLS domain, information from that | ||||
message is encoded into mLDP messages. When the mLDP messages are | ||||
received at 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 result is an IP multicast tree consisting of a set of IP | ||||
multicast 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 to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. | |||
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. | ||||
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), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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 | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on July 22, 2010. | This Internet-Draft will expire on August 30, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | 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 BSD License. | ||||
When an IP multicast tree needs to pass through an MPLS domain, it is | This document may contain material from IETF Documents or IETF | |||
advantageous to map the tree to a Point-to-Multipoint or Multipoint- | Contributions published or made publicly available before November | |||
to-Multipoint Label Switched Path. This document specifies a way to | 10, 2008. The person(s) controlling the copyright in some of this | |||
provide a one-one mapping between IP multicast trees and Label | material may not have granted the IETF Trust the right to allow | |||
Switched Paths using mLDP signaling. The IP multicast control | modifications of such material outside the IETF Standards Process. | |||
messages are translated into MPLS control messages when they enter | Without obtaining an adequate license from the person(s) controlling | |||
the MPLS domain, and are translated back into IP multicast control | the copyright in such materials, this document may not be modified | |||
messages at the far end of the MPLS domain. The IP multicast control | outside the IETF Standards Process, and derivative works of it may | |||
information is coded into the MPLS control information in such a way | not be created outside the IETF Standards Process, except to format | |||
as to ensure that a single Multipoint Label Switched Path gets set up | it for publication as an RFC or to translate it into languages other | |||
for each IP multicast tree. | 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 IP multicast source trees . . . . . . . . . . . 6 | 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 5 | |||
2.2. Transiting IP multicast bidirectional trees . . . . . . . 6 | 2.2. Transiting IP multicast source trees . . . . . . . . . . . 5 | |||
2.3. Transiting IP multicast shared Trees . . . . . . . . . . . 7 | 2.3. Transiting IP multicast bidirectional trees . . . . . . . 6 | |||
3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 | 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 | 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 | |||
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 | 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 7 | |||
3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8 | 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9 | 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10 | 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
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 | |||
skipping to change at page 4, line 22 | skipping to change at page 4, line 22 | |||
particular enduser multicast packets with any particular LSP. Other | particular enduser multicast packets with any particular LSP. Other | |||
drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in | drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in | |||
which out-of-band signaling protocols, such as PIM and BGP, are used | which out-of-band signaling protocols, such as PIM and BGP, are used | |||
to establish the mapping between an LSP and the multicast packets | to establish the mapping between an LSP and the multicast packets | |||
that need to be forwarded over the LSP. | that 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 | source-specific tree or a bidirectional tree) enters the MPLS network | |||
network, the IP multicast control messages used to set up the tree | the (S,G) or (*,G) information from the IP multicast control plane | |||
are translated into mLDP messages. The (S,G) or (*,G) information | state is carried in the opaque value field of the mLDP FEC message. | |||
from the IP multicast control messages is carried in the opaque value | As the tree leaves the MPLS network, this information is extracted | |||
field of the mLDP FEC message. As the tree leaves the MPLS network, | from the FEC element and used to build the IP multicast control | |||
this information is extracted from the FEC element and used to build | plane. PIM messages can be sent outside the MPLS domain. Note that | |||
the IP multicast control messages that are sent outside the MPLS | although the PIM control messages are sent periodically, the mLDP | |||
domain. Note that although the IP multicast control messages are | messages are not. | |||
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. This type of service works well if the number of | |||
LSPs that are created is under control of the MPLS network operator, | LSPs that are created is under control of the MPLS network operator, | |||
or if the number of LSPs for a particular service are known to be | or if the number of LSPs for a particular service are known to be | |||
limited in number. | limited in number. | |||
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", | |||
skipping to change at page 5, line 12 | skipping to change at page 5, line 12 | |||
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. | mLDP : Multicast 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 | |||
signal multicast route information. | carry the (S,G) or (*,G) indentifying a particular IP multicast | |||
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, acting | |||
indifferently as ingress or egress. | indifferently 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. | |||
skipping to change at page 5, line 35 | skipping to change at page 5, line 36 | |||
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 has the desire to create 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] or RP discovery. Suppose | MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto- | |||
that D can determine that the IP multicast tree needs to travel | discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery. | |||
through the MPLS network until it reaches some other LSR, U. For | Suppose that D can determine that the IP multicast tree needs to | |||
instance, when D looks up the route to the Source or Rendezvous Point | travel through the MPLS network until it reaches some other LSR, U. | |||
(RP) [RFC4601] of the IP multicast tree, it may discover that the | For instance, when D looks up the route to the Source or Rendezvous | |||
route is a BGP route with U as the BGP next hop. Then D may chose to | Point (RP) [RFC4601] of the IP multicast tree, it may discover that | |||
set up a P2MP or MP2MP LSP, with U as root, and to make that LSP | the route is a BGP route with U as the BGP next hop. Then D may | |||
become part of the IP multicast distribution tree. Note that other | chose to set up a P2MP or MP2MP LSP, with U as root, and to make that | |||
methods are possible to determine that an IP multicast tree is to be | LSP become part of the IP multicast distribution tree. Note that | |||
transported across an MPLS network using P2MP or MP2MP LSPs, these | other methods are possible to determine that an IP multicast tree is | |||
methods are outside the scope of this document. | to be transported across an MPLS network using P2MP or MP2MP LSPs, | |||
these 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. | |||
In order to send the multicast stream via a P2MP or MP2MP LSP using | Multicast groups that operate in PIM Dense-Mode are outside the scope | |||
in-band signaling the source and the group will be encoded into an | of this document. | |||
mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of | ||||
In order to transport the 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) | 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 stream. 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 will be executed. If the opaque encoding of the FEC | procedure is executed. If the opaque encoding of the FEC indicates | |||
indicates this is an Transit LSP (indicated by the opaque type), the | this is a Transit LSP (indicated by the opaque type), the opaque TLV | |||
opaque TLV will be decoded and the multicast source and group is | is decoded and the multicast source and group is passed to the | |||
passed to the multicast code. If the multicast tree information was | multicast code. If the multicast tree information is received via a | |||
received via a label mapping, the multicast code will effectively | label mapping, the multicast code will adds the downstream LDP | |||
treat this as a positif indication to create a IP multicast tree | neighbor to the olist of the corresponding (S,G) or (*,G) state, | |||
based on the received information. If it was due to a label | creating such state if it does not already exist. If it is due to a | |||
withdraw, the multicast code will effectively treat this as having | label withdraw, the multicast code will remove the downstream LDP | |||
received a negative indication and it will remove the tree | neighbor from the olist of the corresponding (S,G) or (*,G) state. | |||
indentified by the encoded information. From this point on normal | From this point on normal PIM processing will occur. | |||
PIM processing will occur. | ||||
2.1. Transiting IP multicast source trees | 2.1. Transiting Unidirectional IP multicast Shared Trees | |||
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 | ||||
possible to prune individual sources from the shared tree without the | ||||
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 | ||||
Trees across a Transit LSP is outside the scope of this draft. | ||||
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] (for example via last hop | SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM | |||
behavior or MSDP [RFC3618]) and MUST be transporting across the MPLS | mode, the usual means of discovering active sources is to join a | |||
network using a P2MP LSP. A Transit LSP may be setup to forward the | sparse mode shared tree. However, this document does not provide any | |||
IP multicast traffic across an MPLS core. If the multicast source is | method of transporting a sparse mode shared tree across an MPLS | |||
reachable in a global table the source and group addresses are | network. To apply the technique of this document to PIM-SM in ASM | |||
encoded into the a transit TLV. Depending on the IP version it is | mode, there must be some other means of discovering the active | |||
either Section 3.1 or Section 3.2. | sources. One possible means is the use of MSDP [RFC3618]. Another | |||
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 | ||||
discovering the active sources is outside the scope of this document, | ||||
and as a result this document does not specify everything that is | ||||
needed to support the ASM service model using in-band signaling. | ||||
2.2. Transiting IP multicast bidirectional trees | The source and group addresses are encoded into the a transit TLV as | |||
specified in Section 3.1 and Section 3.2. | ||||
2.3. Transiting IP multicast bidirectional trees | ||||
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; only the group address and subnet mask are | a specific source address; the group address, subnet mask and RP are | |||
relevant for multicast forwarding. The RP for the group already | relevant for multicast forwarding. This document does not provide | |||
known by IP multicast is used to select the ingress PE and root of | procedures to discover RP to group mappings dynamically across an | |||
the LSP. The group address is encoded in either Section 3.3 or | MPLS network and assumes the RP is statically defined. Support of | |||
Section 3.4, depending on the IP version. The subnet mask associated | dynamic RP mappings in combination with in-band signaling is outside | |||
with the bidirectional group is encoded in the Transit TLV. There | the scope of his document. | |||
are two types of bidirection states in IP multicast, the group | ||||
specific state and the RPA state. The first type is typlically | ||||
created due to receiving a PIM join and has a subnet mask of 32 for | ||||
IPv4 and 128 for IPv6, the latter is typically created via the RP | ||||
mapping protocol and has a variable subnet mask. The RPA state is | ||||
used to build a tree to the RP and used for sender only branches. | ||||
Please see [RFC5015] for more details. | ||||
2.3. Transiting IP multicast shared Trees | The RP for the group is used to select the ingress PE and root 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 | ||||
mask associated with the bidirectional group is encoded in the | ||||
Transit TLV. There are two types of bidirectional states in IP | ||||
multicast, the group specific state and the RPA state. The first | ||||
type 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 | ||||
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 | ||||
only branches. Each state (group specific and RPA state) will result | ||||
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 | ||||
for PIM to merge the two LSPs, each LSP is effectively treated as a | ||||
PIM enabled interface. Please see [RFC5015] for more details. | ||||
Nothing prevents PIM shared trees from being transported across a | In order transport the packets of sender only branch to the root of | |||
MPLS core. However, it is not possible to prune of individual | the LSP a MP2MP is created. This will cause the sender only branches | |||
sources from the shared tree without the use of an additional out-of- | to receive each others packets. These packets will be dropped and | |||
band signaling protocol, like PIM. For that reason transiting Shared | not forwarded, if that affect is undesireable some other means of | |||
Trees across a Transit LSP is outside the scope of this draft. | 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 | ||||
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.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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 11, line 36 | skipping to change at page 12, line 16 | |||
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] | [I-D.ietf-mpls-ldp-p2mp] | |||
Minei, I., "Label Distribution Protocol Extensions for | Minei, I., Kompella, K., Wijnands, I., and B. Thomas, | |||
Point-to-Multipoint and Multipoint-to-Multipoint Label | "Label Distribution Protocol Extensions for Point-to- | |||
Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in | Multipoint and Multipoint-to-Multipoint Label Switched | |||
progress), June 2008. | Paths", draft-ietf-mpls-ldp-p2mp-08 (work in progress), | |||
October 2009. | ||||
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] | [I-D.ietf-l3vpn-2547bis-mcast] | |||
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., | Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., | |||
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in | Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in | |||
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work | MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work | |||
in progress), July 2008. | in progress), January 2010. | |||
[I-D.rekhter-pim-sm-over-mldp] | ||||
Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode | ||||
Trees over P2MP mLDP LSPs", | ||||
draft-rekhter-pim-sm-over-mldp-00 (work in progress), | ||||
November 2009. | ||||
[I-D.rosen-l3vpn-mvpn-mspmsi] | ||||
Boers, A., Cai, Y., Napierala, M., Rosen, E., and I. | ||||
Wijnands, "MVPN: Optimized use of PIM via MS-PMSIs", | ||||
draft-rosen-l3vpn-mvpn-mspmsi-06 (work in progress), | ||||
February 2010. | ||||
Authors' Addresses | Authors' Addresses | |||
IJsbrand Wijnands | IJsbrand Wijnands | |||
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. 25 change blocks. | ||||
113 lines changed or deleted | 166 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |