Internet DRAFT - draft-brockners-ldp-half-duplex-mp2mp
draft-brockners-ldp-half-duplex-mp2mp
Network Working Group F. Brockners
I. Wijnands
Internet Draft A. Sajassi
Intended status: Standards Track Cisco Systems
Expires: August 22, 2008 February 22, 2008
Label Distribution Protocol Extensions for Half-Duplex
Multipoint-to-Multipoint Label Switched Paths
draft-brockners-ldp-half-duplex-mp2mp-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/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 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Brockners Expires August 22, 2008 [Page 1]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
Abstract
This document describes a mechanism to construct Label Switched Paths
(LSP) over MPLS using an extended version of the Label Distribution
Protocol (LDP) between a set of clients and servers. This
communication mechanism has the capability that servers can
communicate with other servers and clients, whereas clients can only
communicate with servers but not with other clients.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction...................................................3
1.1. Service Connectivity Categorization.......................3
1.2. Problem Statement and Motivation..........................4
1.3. Terminology (for reference only)..........................5
2. Half duplex MP2MP (HD-MP2MP) Service with LDP..................6
2.1. FEC elements for HD-MP2MP.................................7
2.2. Using the HD-MP2MP FEC elements: Notation.................8
2.3. HD-MP2MP Label Mapping...................................10
2.3.1. Determining one's upstream MP2MP LSR................10
2.3.2. Determining one's downstream MP2MP LSR..............10
2.3.3. HD-MP2MP client leaf node operation.................10
2.3.4. HD-MP2MP server leaf node operation.................11
2.3.5. Transit node operation..............................12
2.3.5.1. Transit node operation overview................12
2.3.5.2. Client Downstream Label Map received...........13
2.3.5.3. Server Downstream Label Map received...........14
2.3.6. HD-MP2MP root node operation........................15
2.3.6.1. Client Downstream Label Map received...........15
2.3.6.2. Server Downstream Label Map received...........16
2.3.7. HD-MP2MP Label Withdraw.............................17
2.3.7.1. HD-MP2MP Client operation......................17
2.3.7.2. HD-MP2MP Server operation......................17
2.3.7.3. HD-MP2MP transit node operation................18
2.3.7.4. HD-MP2MP root node operation...................18
2.3.7.5. HD-MP2MP Upstream LSR Change...................18
3. Security Considerations.......................................19
4. IANA Considerations...........................................19
5. References....................................................19
5.1. Normative References.....................................19
Brockners Expires August 22, 2008 [Page 2]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
5.2. Informative References...................................19
Author's Addresses...............................................20
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................21
1. Introduction
The LDP protocol is described in [1]. It defines mechanisms for
setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs
in the network. This document describes a mechanism to construct
Half-Duplex Multipoint to Multipoint LSPs (HD-MP2MP LSPs) over an
MPLS infrastructure using LDP.
1.1. Service Connectivity Categorization
The following general types of connectivity using some transport
vehicle (e.g. a LSP) are acknowledged within the industry (see e.g.
[8]) between a set of User to Network (UNI) interfaces:
o Point to Point Connectivity: For Point-to-Point connectivity,
exactly two UNIs are associated with one another. An ingress
service frame mapped to the transport vehicle at one UNI shall not
result in an egress service frame at a UNI other than the other
UNI associated with the transport vehicle.
o Multipoint Connectivity: For Multipoint connectivity two or more
UNIs are associated with one another. An ingress service frame
mapped to the transport vehicle at one of the UNIs shall not
result in an egress service frame at a UNI that is not associated
with the transport vehicle. Multipoint connectivity can further be
differentiated into multipoint to multipoint connectivity as well
as rooted-multipoint connectivity.
* Multipoint to Multipoint Connectivity: An ingress service frame
at a given UNI would be replicated in the network and a single
copy would be delivered to each of the other UNIs associated
with the transport vehicle.
* Rooted-Multipoint Connectivity: For rooted multipoint
connectivity, one or more of the UNIs shall be designated as a
servers and each of the other UNIs shall be designated as a
clients. An ingress service frame mapped to the transport
vehicle at a server UNI should be delivered to one or more of
the other UNIs. An ingress service frame mapped to the
transport vehicle at a client UNI shall not result in an
egress service frame at another client UNI but can result in
an egress service frame at some or all of the server UNIs.
Brockners Expires August 22, 2008 [Page 3]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
Using the LDP Protocol [1], one can establish point to point as well
as multipoint connectivity using LSPs. For multipoint operation,
multipoint to multipoint, point to multipoint as well as multipoint
to point connectivity models are supported. While rooted-multipoint
connectivity can be established by combining point to multipoint with
multipoint to point LSPs, a more efficient mechanism to establish
rooted-multipoint connectivity (which could be understood as a
generalized version of point to multipoint connectivity) is
desirable. Half-Duplex MDT with LDP can be leveraged to establish
rooted multipoint connectivity.
1.2. Problem Statement and Motivation
Some deployment scenarios, such as broadcast TV delivery over
aggregation networks or broadcast/multicast wholesale require
efficient mechanisms to transport multicast/broadcast type of data
from a set of sources to many receivers over an MPLS network, while
isolating the receivers from each other. Achieving such a
connectivity model with a limited amount of configuration on the leaf
nodes is seen as beneficial.
The desired behavior is as follows:
o The set of users can be divided into two non-overlapping sets:
Client nodes (or short "Clients") and server nodes (or short
"Servers").
o Servers can communicate with each other and with the clients, i.e.
Servers can send data to each other as well as to clients and can
receive data from each other as well as from clients.
o Clients can only communicate with servers, i.e. Clients can send
data to servers and can receive data from servers but cannot send
data to other clients nor can receive data from other clients.
o All data is transported as broadcast: Any data sent by a server is
received by all other servers and all clients. Any data sent by a
client is received by all servers.
o The setup of the forwarding behavior between clients and servers
should be automatic, i.e. should not require any configuration on
network elements other than the client and server nodes.
Provisioning a new client should not require any manual
reconfiguration but on the client itself.
As a result of this behavior, a local connectivity between clients is
prevented and it is ensured that connectivity between clients can
Brockners Expires August 22, 2008 [Page 4]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
only be provided through server sites. This ensures that in a
broadband aggregation deployment case, individual subscribers cannot
directly connect with each other, bypassing functions implemented on
the edge router such as accounting or admission control.
One way to achieve the desired communication behavior with restricted
connectivity between clients is to use a combination of LDP P2MP LSPs
and LDP MP2P LSPs: One P2MP LSP per server (with the server forming
the root of the P2MP LSP and the clients other servers forming the
leaves) would be established for server to client (and other servers)
communication. One MP2P LSP per server (forming the root of the MP2P
tree) would be used to enable clients and other servers to
communicate with the server forming the root. As a result, each
client is connected to N P2MP LSPs and N MP2P LSPs, with N
representing the number of servers.
The major advantage of this approach is that no further protocol
mechanisms beyond the ones already defined in [1] and [7] would be
required.
A property of this approach is that clients need to handle send and
receive operations across multiple LSPs for the same service
instance. Clients wishing to send traffic to the set of servers are
required to send the data multiple times (once per server, or in
other words once per MP2P LSP). Furthermore, the addition or removal
of a server from the overall configuration would also require
configuration changes on all connected servers and clients.
HD-MP2MP LSP described here aim at reducing the configuration
requirements on the leaf nodes, so that clients or servers can be
added without a reconfiguration on other clients or servers and at
simplifying traffic handling by using only a single LSP to send data
to and a single LSP to receive data from.
1.3. Terminology (for reference only)
The following terminology is taken from [4] and is repeated here to
ease readability of the document.
o P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
o P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs.
o MP2P LSP: A LSP that has one or more Ingress LSRs and one unique
o Egress LSR.
Brockners Expires August 22, 2008 [Page 5]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
o MP2MP LSP: A LSP that connects a set of leaf nodes, acting
indifferently as ingress or egress.
o MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
o Ingress LSR: Source of the P2MP LSP, also referred to as root
node.
o Egress LSR: One of potentially many destinations of an LSP, also
referred to as leaf node in the case of P2MP and MP2MP LSPs.
o Transit LSR: An LSR that has one or more directly connected
downstream LSRs.
o Bud LSR: An LSR that is an egress but also has one or more
directly connected downstream LSRs.
To ease readability of this document this section briefly lists the
notation for the P2MP FEC element as they are described in [7].
Please refer to [7] for a comprehensive description.
o P2MP FEC Element <X, Y>: a FEC Element with Root Node Address X
and Opaque Value Y.
o P2MP Label Map <X, Y, L>: a Label Map message with a FEC TLV with
a single P2MP FEC Element <X, Y> and Label TLV with label L.
o P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC
TLV with a single P2MP FEC Element <X, Y> and Label TLV with label
L.
o P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with Root Node
Address X and Opaque Value Y.
o The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X
means that on receiving a packet with label L', X makes n copies
of the packet. For copy i of the packet, X swaps L' with Li and
sends it out over interface Ii.
2. Half duplex MP2MP (HD-MP2MP) Service with LDP
An HD-MP2MP combines two LSPs. The LSPs used to construct a HD-MP2MP
service are similar to a MP2MP LSP in that it consists of a single
root node, zero or more transit nodes and one or more leaf LSRs
acting equally as Ingress or Egress LSR. Leaf LSRs fulfill either the
Brockners Expires August 22, 2008 [Page 6]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
role of a client or a server. Correspondingly they are called "Client
LSR" and "Server LSR".
For HD-MP2MP operation, two trees will be combined: A "Client Tree"
which allows communication from all Clients to all Servers and a
"Server Tree" allows communication from all servers to all clients
and all servers.
A leaf node participates in the setup of a HD-MP2MP LSP by
establishing both a downstream LSP, which is much like a P2MP LSP
from the root, and an upstream LSP which is used to send traffic
toward the root and other leaf nodes. Depending on the type of the
leaf (Client or Server), traffic sent by a leaf will either be
forwarded to all leafs (which means clients and servers - this is in
case of a leaf being a server), or only to servers (in case of a leaf
being a client).
Transit nodes support the setup by propagating the upstream and
downstream LSP setup toward the root and installing the necessary
MPLS forwarding state.
Traffic from a client leaf node follows the upstream LSP towards the
root node and branches downward along the downstream LSP as required
to reach other server nodes (but no other client nodes). Similarly,
traffic from a server leaf node follows the upstream LSP toward the
root node and branches downward along the downstream LSP as required
to reach client nodes and server nodes.
Mapping traffic to the HD-MP2MP LSP may happen at any leaf node (the
root may be a leaf node as well). How that mapping is established is
outside the scope of this document.
Due to how a HD-MP2MP LSP is built a leaf LSR that is sending packets
on the HD-MP2MP LSP does not receive its own packets. There is also
no additional mechanism needed on the root or transit LSR to match
upstream traffic to the downstream forwarding state.
For the setup of a HD-MP2MP LSP with LDP we expand the definition of
downstream FEC elements (as defined in [7]) to differentiate leaf
notes into servers and clients. Both elements will be used in the FEC
TLV. The descriptions of the HD-MP2MP FEC elements follow.
2.1. FEC elements for HD-MP2MP
HD-MP2MP leverages the structure, encoding and error handling of the
P2MP FEC elements as described in [7]. This means that the P2MP FEC
element, which consists of the address of the root of the P2MP LSP
Brockners Expires August 22, 2008 [Page 7]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
and an opaque value are being used as defined in [7]. The opaque
value is unique within the context of the root node and can for
example be interpreted as a service instance identifier. The
combination of (Root Node Address, Opaque Value) uniquely identifies
a P2MP LSP within the MPLS network.
Four new FEC types are introduced for HD-MP2MP operation:
o C-FEC-UP: HD-MP2MP Client Upstream Type (TBD)
o C-FEC-DOWN: HD-MP2MP Client Downstream Type (TBD)
o S-FEC-UP: HD-MP2MP Server Upstream Type (TBD)
o S-FEC-DOWN: HD-MP2MP Server Downstream Type (TBD)
If a FEC TLV contains one of the HD-MP2MP FEC elements, the HD-MP2MP
FEC Element MUST be the only FEC Element in the FEC TLV.
2.2. Using the HD-MP2MP FEC elements: Notation
The following notation is used in the processing rules:
1. HD-MP2MP client downstream LSP <X, I> (or simply client downstream
<X, I>): a MP LSP downstream path with root node address X and
opaque value I.
2. HD-MP2MP server downstream LSP <X, I> (or simply server downstream
<X, I>): a MP LSP downstream path with root node address X and
opaque value I.
3. HD-MP2MP client upstream LSP <X, I, D> (or simply client upstream
<X, I, D>): a MP LSP upstream path for downstream node D with root
node address X and opaque value I.
4. HD-MP2MP server upstream LSP <X, I, D> (or simply server upstream
<X, I, D>): a MP LSP upstream path for downstream node D with root
node address X and opaque value I.
5. HD-MP2MP Client Downstream FEC element <X, I>: a FEC element with
root node address X and opaque value I used for a client type
downstream HD-MP2MP LSP.
6. HD-MP2MP Server Downstream FEC element <X, I>: a FEC element with
root node address X and opaque value I used for a server type
downstream HD-MP2MP LSP.
Brockners Expires August 22, 2008 [Page 8]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
7. HD-MP2MP Client Upstream FEC element <X, I>: a FEC element with
root node address X and opaque value I used for a client type
downstream HD-MP2MP LSP.
8. HD-MP2MP Server Upstream FEC element <X, I>: a FEC element with
root node address X and opaque value I used for a server type
downstream HD-MP2MP LSP.
9. HD-MP2MP Client Downstream Label Map <X, I, L>: A Label Map
message with a FEC TLV with a single HD-MP2MP Client Downstream
FEC element <X, I> and label TLV with label L.
10.HD-MP2MP Server Downstream Label Map <X, I, L>: A Label Map
message with a FEC TLV with a single HD-MP2MP Server Downstream
FEC element <X, I> and label TLV with label L.
11.HD-MP2MP Client Upstream Label Map <X, I, Lu>: A Label Map message
with a FEC TLV with a single HD-MP2MP Client Upstream FEC element
<X, I> and label TLV with label L.
12.HD-MP2MP Server Upstream Label Map <X, I, Lu>: A Label Map message
with a FEC TLV with a single HD-MP2MP Server Upstream FEC element
<X, I> and label TLV with label Lu.
13.HD-MP2MP Client Downstream Label Withdraw <X, I, L>: A Label
Withdraw message with a FEC TLV with a single HD-MP2MP Client
Downstream FEC element <X, I> and label TLV with label L.
14.HD-MP2MP Server Downstream Label Withdraw <X, I, L>: A Label
Withdraw message with a FEC TLV with a single HD-MP2MP Server
Downstream FEC element <X, I> and label TLV with label L.
15.HD-MP2MP Client Upstream Label Withdraw <X, I, Lu>: A Label
Withdraw message with a FEC TLV with a single HD-MP2MP Client
Upstream FEC element <X, I> and label TLV with label L.
16.HD-MP2MP Server Upstream Label Withdraw <X, I, Lu>: A Label
Withdraw message with a FEC TLV with a single HD-MP2MP Server
Upstream FEC element <X, I> and label TLV with label Lu.
The procedures below are organized by the role which the node plays
in the HD-MP2MP LSP: Leaf nodes, transit nodes and server node.
A leaf node is identified by a discovery process which is outside the
scope of this document. During the course of the protocol operation,
the root node recognizes its role because it owns the root node
address. A transit node is any node (other then the root node) that
Brockners Expires August 22, 2008 [Page 9]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
receives a HD-MP2MP Label Map message (i.e., one that has leaf nodes
downstream of it).
Note that a transit node (as well as the root node) may also be a
leaf node.
2.3. HD-MP2MP Label Mapping
The following lists procedures for generating and processing HD-MP2MP
Label Map messages for nodes that participate in a HD-MP2MP LSP.
Based on its role in the HD-MP2MP LSP a LSR should apply the
procedures associated to its role.
Optimization procedures for multiple receivers on a LAN are not
considered in this document. This is a subject for further study, see
[5].
The following notation is used in the descriptions below:
U
|
|
Z (transit node)
|
|
D (e.g. leaf)
2.3.1. Determining one's upstream MP2MP LSR
Determining the upstream LDP peer U for a HD-MP2MP LSP <X, I> follows
the procedure for a P2MP LSP described in [7].
2.3.2. Determining one's downstream MP2MP LSR
A LDP peer U which receives a HD-MP2MP Label Map downstream from a
LDP peer D will treat D as downstream MP2MP LSR.
2.3.3. HD-MP2MP client leaf node operation
Generally speaking, a client LSR joins the server tree for receive
operations and the client tree for send operations.
A client leaf node D determines its upstream LSR Z for server
downstream <X, I> as per the procedures described in [7], allocates a
label L, and sends a server downstream label map <X, I, L> to Z.
Brockners Expires August 22, 2008 [Page 10]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
Traffic received with Label L represents traffic which another server
had sent.
Leaf node D expects a client upstream label map <X, I, Lz> from node
Z in response to the HD-MP2MP server label map downstream it sent to
node Z. This will allow the client to send data to servers.
In case D does not already have forwarding state for client upstream
<X, I>, D creates forwarding state to push label Lz onto the traffic
that D wants to forward to servers. How it determines what traffic
to forward on this HD-MP2MP LSP is outside the scope of this
document.
In summary, a client uses
o Client upstream <X, I> and label Lz to send data to servers
o Server downstream <X, I> and label L to receive data from servers
2.3.4. HD-MP2MP server leaf node operation
Generally speaking, a server LSR joins the client tree for receive
operations and the server tree for send operations. Transit LSR and
the root LSR will perform appropriate label mappings to ensure that
traffic sourced by server LSR is received via the client tree.
A server leaf node D determines its upstream LSR Z for client
downstream <X, I> as per the procedures described in [7], allocates a
label L, and sends a client downstream label map <X, I, L> to Z.
Traffic received with Label L represents traffic which another server
or client had sent.
Leaf node D expects a server upstream label map <X, I, Lz> from node
Z in response to the HD-MP2MP client label map downstream it sent to
node Z. This will allow the server to send data to servers and
clients.
In case D does not already have forwarding state for server upstream
<X, I>, D creates forwarding state to push label Lz onto the traffic
that D wants to forward to servers and clients. How it determines
what traffic to forward on this HD-MP2MP LSP is outside the scope of
this document.
In summary, a server uses
o Server upstream <X, I> and label Lz to send data to servers and
clients.
Brockners Expires August 22, 2008 [Page 11]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
o Client downstream <X, I> and label L to receive data from servers
and clients.
2.3.5. Transit node operation
2.3.5.1. Transit node operation overview
This section provides a high-level overview of the operation of a
transit node.
Label Map signaling:
o On receipt of a "client downstream" label map, transit nodes
respond with a "server upstream" label map. This is commonly the
case if a server joins the HD-MDT. If the transit node does not
have forwarding state towards the root for the corresponding HD-
MDT, it will also send a "client downstream" label map towards the
root.
o On receipt of a "server downstream" label map, transit nodes
respond with a "client upstream" label map. This is commonly the
case if a client joins the HD-MDT. If the transit node does not
have forwarding state for towards the root for the corresponding
HD-MDT, it will also send a "server downstream" label map towards
the root.
Forwarding state establishment:
o Transit nodes update their forwarding state according to the
client downstream / server downstream label map messages.
o In order to ensure that servers receive traffic from clients (i.e.
ensure that traffic from clients is sent down the tree towards
servers while omitting the interface the traffic is received on),
transit nodes copy forwarding state from client downstream to
client upstream state tables - except for the interfaces these
state tables are associated with.
o In order to ensure that clients receive traffic from servers (i.e.
ensure that traffic from servers is sent down the tree towards
clients while omitting the interface the traffic is received on),
transit nodes copy forwarding state from server downstream to
server upstream state tables - except for the interfaces these
state tables are associated with.
Brockners Expires August 22, 2008 [Page 12]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
o In order to ensure that servers receive traffic from servers (i.e.
ensure that traffic from servers is sent down the tree towards
servers while omitting the interface the traffic is received on),
transit nodes copy forwarding state from client downstream to
server upstream state tables - except for the interfaces these
state tables are associated with.
2.3.5.2. Client Downstream Label Map received
Transit nodes receive a client downstream label map as the result of
a server joining the HD-MDT.
When node Z receives a HD-MP2MP client downstream label map <X, I, L>
over interface Q from node D it checks whether it has forwarding
state for client downstream <X, I>. If not, Z allocates a label L'
and installs downstream forwarding state to swap label L' with label
L over interface Q towards node D. Z also determines its upstream LSR
U for <X, I> as per [7] and sends a client label map downstream <X,
I, L') upstream to U.
If Z already has forwarding state for client downstream <X, I>, Z
needs to update its forwarding state. Assuming its old forwarding
state was L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>}, its new forwarding
state becomes L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>, <Q, L>}.
Node Z checks whether it has forwarding state(s) for client upstream
<X, I, D(i)>. If so node Z will update the forwarding state(s) for
client upstream <X, I, D(i)> to include the forwarding state from
client downstream <X, I> omitting the swap on the interfaces
associated with node D(i). This allows client upstream traffic to
follow the client downstream tree to other servers while omitting the
case that traffic is sent out on the same interface it was received
from.
Node Z checks whether it already has forwarding state server upstream
<X, I , D> over interface Q. If it does, no further action needs to
happen. Otherwise, Z allocates a label Lz and creates a new label
swap for Lz from the label swap(s) from the forwarding state for
server downstream <X, I>, omitting the swap on interface Q for node
D. This allows server upstream traffic to follow the server
downstream tree down to other node(s) except the node from which Z
received the client downstream label map <X, I, L>.
In addition Z will update the forwarding state(s) for server upstream
<X, I, D(i)> to include the forwarding state from client downstream
<X, I> omitting label swaps on interfaces Q(i) for nodes D(i), i.e.
omitting receive and forwarding label swaps referring to the same
interface. This is to avoid traffic being sent out the same interface
it was received from. This allows server upstream traffic to follow
Brockners Expires August 22, 2008 [Page 13]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
the client downstream tree to other servers.
Z sends a server upstream label map <X, I, Lz) over Interface Q to
node D.
Transit node Z will also receive a server upstream label map <X, I,
Lu) in response to the client downstream label map <X, I, L') sent
upstream to node U over interface Qu. Node Z will add a label swap Lu
over interface Qu to the forwarding state for server upstream <X, I,
D>. This allows packets to go up the server tree towards the root
node.
2.3.5.3. Server Downstream Label Map received
Transit nodes receive a server downstream label map as the result of
a client joining the HD-MDT.
When node Z receives a HD-MP2MP server downstream label map <X, I, L>
over Interface Q from node D it checks whether it has forwarding
state for server downstream <X, I>. If not, Z allocates a label L'
and installs downstream forwarding state to swap label L' with label
L over interface Q. Z also determines its upstream LSR U for <X, I>
as per [7] and sends a server label map downstream <X, I, L')
upstream to U.
If Z already has forwarding state for server downstream <X, I>, all
that Z needs to do is to update its forwarding state. Assuming its
old forwarding state was L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>}, its
new forwarding state becomes L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>,
<Q, L>}.
Node Z checks whether it already has forwarding state for client
upstream <X, I, D> over interface Q. If it does, no further action
needs to happen. Otherwise, Z allocates a label Lz and creates a new
label swap for Lz from the label swap(s) from the forwarding state
for client downstream <X, I>, omitting the swap on interface Q for
node D. This allows client upstream traffic to follow the client
downstream tree down to other node(s) (i.e. servers) except to the
node from which Z received the server downstream label map <X, I, L>.
In addition, Z sends a client upstream label map <X, I, Lz) over
Interface Q to node D.
Node Z checks whether it has forwarding state for server upstream <X,
I, D(i)>. If so node Z will update the forwarding state(s) for server
upstream <X, I, D(i)> to include the newly added forwarding state for
server downstream, i.e. to include <Q, L>, omitting the swap on
interface Q for node D. This allows server upstream traffic to follow
the server downstream tree down to other node(s) (i.e. clients).
Brockners Expires August 22, 2008 [Page 14]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
Transit node Z will also receive a client upstream label map <X, I,
Lu) in response to the server downstream label map <X, I, L') sent
upstream to node U over interface Qu. Node Z will add a label swap Lu
over interface Qu to the forwarding state client upstream <X, I, D>.
This allows packets to go up towards the root node.
2.3.6. HD-MP2MP root node operation
2.3.6.1. Client Downstream Label Map received
Operation of a root node is similar to the operation of a transit
node with the main difference that by definition the root node does
not have an upstream neighbor. As such there is no need for the root
to send any (client or server) downstream label map.
When root R receives a HD-MP2MP client downstream label map <X, I, L>
over interface Q from node D it checks whether it has forwarding
state for client downstream <X, I>. If not, R creates downstream
forwarding state and installs an outgoing label L over interface Q.
If R already has forwarding state for client downstream <X, I>, R
needs to update its forwarding state. Assuming its old forwarding
state was L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>}, its new forwarding
state becomes L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>, <Q, L>}.
Root node R checks whether it has forwarding state for client
upstream <X, I, D(i)>. If so root node R will update the forwarding
state for client upstream <X, I, D(i)> to include the forwarding
state from client downstream <X, I> omitting the swap on the
interfaces associated with node D(i). This allows client upstream
traffic to follow the client downstream tree to other servers while
omitting the case that traffic is sent out on the same interface it
was received on.Root node R checks whether it already has forwarding
state server upstream <X, I , D> over interface Q. If it does, no
further action needs to happen. Otherwise, R allocates a label Lr and
creates a new label swap for Lr from the label swap(s) from the
forwarding state for server downstream <X, I>, omitting the swap on
interface Q for node D. This allows server upstream traffic to follow
the server downstream tree down to other node(s) except the node from
which Z received the client downstream label map <X, I, L>. In
addition Z will update the forwarding state(s) for server upstream
<X, I, D(i)> to include the forwarding state from client downstream
<X, I> omitting label swaps on interfaces Q(i) for nodes D(i), i.e.
labels swaps referring to the same interface. This is to avoid
traffic being sent out the same interface it was received from. This
allows server upstream traffic to follow the client downstream tree
Brockners Expires August 22, 2008 [Page 15]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
to other servers.
Root node R determines the downstream LSR D as per the procedures
described in [7], and sends a server upstream label map <X, I, Lu) to
node D.
Since R is the root node, there is no need to send any client
downstream label map.
2.3.6.2. Server Downstream Label Map received
When root node R receives a server downstream label map <X, I, L>
over Interface Q from node D it checks whether it has forwarding
state for server downstream <X, I>. If not, R creates server
downstream forwarding state and installs an outgoing label L over
interface Q. If R already has forwarding state for server downstream
<X, I>, the R will add label L over interface Q to the existing
state.
Node R checks if it has forwarding state for server upstream <X, I,
D>. If not, R allocates a label Lu and creates forwarding state to
swap Lu with the label swap(s) from the forwarding state downstream
(X, I), except the swap for node D. This allows server upstream
traffic to go down the server tree to other node(s), except the node
it was received from.
When root node R receives a server downstream label map <X, I, L>
over Interface Q from node D it checks whether it has forwarding
state for server downstream <X, I>. If not, R creates server
downstream forwarding state and installs an outgoing label L over
interface Q.
If R already has forwarding state for server downstream <X, I>, R
updates its forwarding state. Assuming its old forwarding state was
L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>}, its new forwarding state
becomes L'-> {<Q1, L1> <Q2, L2> ..., <Qn, Ln>, <Q, L>}.
Node R checks whether it already has forwarding state for client
upstream <X, I, D> over interface Q. If it does, no further action
needs to happen. Otherwise, R allocates a label Lr and creates a new
label swap for Lr from the label swap(s) from the forwarding state
for client downstream <X, I>, omitting the swap on interface Q for
node D. This allows client upstream traffic to follow the client
downstream tree down to other node(s) (i.e. servers) except to the
node from which R received the server downstream label map <X, I, L>.
Brockners Expires August 22, 2008 [Page 16]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
Root node R checks whether it has forwarding state for server
upstream <X, I, D>. If so node R will update the forwarding state(s)
for server upstream <X, I, D(i)> to include the newly added
forwarding state for server downstream, i.e. to include <Q, L>,
omitting the swap on interface Q for node D. This allows server
upstream traffic to follow the server downstream tree down to other
node(s) (i.e. clients).
Root node R determines the downstream LSR D as per the procedures
described in [7], and sends a client upstream label map <X, I, Lu) to
node D.
2.3.7. HD-MP2MP Label Withdraw
The following lists procedures for generating and processing HD-MP2MP
Label Withdraw messages for nodes that participate in a HD-MP2MP LSP.
These procedures are similar to those for MP2MP described in [7].
An LSR should apply those procedures that apply to it, based on its
role in the HD-MP2MP LSP.
2.3.7.1. HD-MP2MP Client operation
Client label withdraw procedures are similar to those for leaf nodes
in MP2MP operation, described in [7].
If a client node Z discovers (by means outside the scope of this
document) that it is no longer a client, it SHOULD send a server
downstream label withdraw <X, I, L> to its upstream LSR U for <X, I>,
where L is the label it had previously advertised to U for <X, I>.
Client node Z expects the upstream router U to respond by sending a
downstream label release for L and a client upstream label withdraw
<X, I, Lu> to remove Lu from the upstream state. Node Z will remove
label Lu from its upstream state and send a label release message
with label Lu to U.
2.3.7.2. HD-MP2MP Server operation
If a server node Z discovers that it is no longer a server it SHOULD
send a client downstream label withdraw <X, I, L> to its upstream LSR
U for <X, I>, where L is the label it had previously advertised to U
for <X, I>.
Server node Z expects the upstream router U to respond by sending a
downstream label release for L and a server upstream label withdraw
<X, I, Lu> to remove Lu from the upstream state. Node Z will remove
Brockners Expires August 22, 2008 [Page 17]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
label Lu from its upstream state and send a label release message
with label Lu to U.
2.3.7.3. HD-MP2MP transit node operation
Leaf label withdraw procedures are similar to those for MP2MP
operation, described in [7].
If a transit node Z receives a server downstream label withdraw
message <X, I, L> from node D, it deletes label L from its forwarding
state for server downstream <X, I> and from all its upstream states
for <X, I>. Node Z sends a label release message with label L to D.
Since D is no longer part of the server downstream forwarding state,
Z cleans up the forwarding state upstream <X, I, D> and sends a
client upstream label withdraw for <X, I, Lu) to node D.
If deleting L from node Z's forwarding state for server downstream
<X, I> results in no state remaining for <X, I> then Z propagates the
server downstream label withdraw <X, I, L> to its upstream node U for
<X, I>.
Similarly, if a transit node Z receives a client downstream label
withdraw message <X, I, L> from node D, it deletes label L from its
forwarding state for client downstream <X, I> and from all its
upstream states for <X, I>. Node Z sends a label release message with
label L to D. Since D is no longer part of the client downstream
forwarding state, Z cleans up the forwarding state upstream <X, I, D>
and sends a server upstream label withdraw for <X, I, Lu) to node D.
If deleting L from node Z's forwarding state for client downstream
<X, I> results in no state remaining for <X, I> then Z propagates the
client downstream label withdraw <X, I, L> to its upstream node U for
<X, I>.
2.3.7.4. HD-MP2MP root node operation
The procedure when the root node of a MP2MP LSP receives a label
withdraw message is the same as for transit nodes, except that the
root node would not propagate the Label Withdraw upstream (as it has
no upstream).
2.3.7.5. HD-MP2MP Upstream LSR Change
The procedure for changing the upstream LSR is the same as documented
in [7], except it is applied to HD-MP2MP FECs using the procedures
described in the earlier sections of this document.
Brockners Expires August 22, 2008 [Page 18]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
3. Security Considerations
The same security considerations apply as for the base LDP
specification, as described in [1].
4. IANA Considerations
This document leverages the new name space (the LDP MP Opaque Value
Element type) introduced in [7] that is to be managed by IANA.
5. References
5.1. Normative References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[4] Roux, J., "Requirements for Point-To-Multipoint Extensions to
the Label Distribution Protocol ", draft-ietf-mpls-mp-ldp-reqs-
03 (work in progress), November 2007.
[5] Aggarwal, R., "MPLS Upstream Label Assignment and Context
Specific Label Space", draft-ietf-mpls-upstream-label-03 (work
in progress), November 2007.
[6] Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment for
RSVP-TE", draft-ietf-mpls-rsvp-upstream-02 (work in progress),
November 2007.
[7] Minei, I., "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-03 (work in progress), July
2007.
[8] Metro Ethernet Forum, Technical Specification MEF 10.1,
"Ethernet Services Attributes Phase 2", November 2006.
5.2. Informative References
[9] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
Brockners Expires August 22, 2008 [Page 19]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
[10] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE
LSPs", RFC 4875, May 2007.
[11] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
draft-ietf-l3vpn-2547bis-mcast-06 (work in progress), January
2008.
Author's Addresses
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249
40549 Duesseldorf
Germany
Email: fbrockne@cisco.com
Ijsbrand Wijnands
Cisco Systems, Inc.
Pegasus Parc, De Kleetlaan 6a
1831 Diegem
Belgium
Email: iwijnand@cisco.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
Brockners Expires August 22, 2008 [Page 20]
Internet-Draft Half-Duplex Multipoint LSPs with LDP February 2008
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Brockners Expires August 22, 2008 [Page 21]
