Internet DRAFT - draft-chen-mpls-mldp-deployment-via-p2p-tunnels
draft-chen-mpls-mldp-deployment-via-p2p-tunnels
Network Working Group E. Chen
Internet-Draft Q. Zhao
Intended status: Standards Track Huawei Technology
Expires: April 27, 2012 October 25, 2011
Deploying mLDP through p2p LSP Tunnels
draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00.txt
Abstract
Label Distribution Protocol (LDP) can be used to set up Point-to-
Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched
Paths. The existing specification for this functionality assumes
that a pair of LDP neighbors which support the P2MP/MP2MP capability
are directly connected. However, the real deployment may not have
all the nodes along the LSP path to be P2MP/MP2MP capable so that the
CapEx of the deployment can be reduced or the deployment of the LDP
P2MP/MP2MP can be in phases instead of updating the whole network.
This document provides a solution for finding the first upstream node
which supports the LDP P2MP/MP2MP along the path from the current
node to the root node.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 27, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Chen & Zhao Expires April 27, 2012 [Page 1]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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 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.
Chen & Zhao Expires April 27, 2012 [Page 2]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification of requirements . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. mLDP deployment through p2p tunnels . . . . . . . . . . . . . 6
2.1. The signaling procedures for deploying mLDP through
p2p tunnels . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol extensions for deploying mLDP through p2p
tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Chen & Zhao Expires April 27, 2012 [Page 3]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
1. Introduction
1.1. Specification of requirements
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 [RFC2119].
1.2. Motivation
This document provides a solution to setup LDP's P2MP and MP2MP LSPs
in a network where where the mLDP LSP passes through nodes which is
not mLDP capable.
The Label Distribution Protocol (LDP) extensions for setting up
Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and
Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This
set of extensions is generally known as "Multipoint LDP" (mLDP). The
term "Multipoint" means "either P2MP or MP2MP" normmally.
In the deployment scenarios where the service providers wish to
upgrade their network gradually by only making certain nodes of the
existing network to be upgraded both on the control plane and
forwarding plane and for the rest of the network nodes, they only
require a minor signaling plan change while keeping the forwarding
plan as same as before. This will reduce the CapEx for the users who
doesn't need to update every nodes of their network to support the
mLDP.
The base specification for mLDP does not explicitly cover the case
where the LDP multipoint extensions are used for over a path where
the transit nodes along path to the root node don't support the mLDP
capability.
If LSR D is setting up the MP-LSP <R, X>, D needs to determine the
"upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>,
U, is defined to be the "next hop" on D's path to root R, and "next
hop" is tacitly assumed to mean "IGP next hop". It is thus assumed
that there is a direct LDP session between D and U. In the deployment
scenario where the "IGP next hop" may not support the mLLDP fearure.
In this specification, we specify a p2p tunnel through method which
identifies an "upstream LSR" which is doesn't have the direct session
with LSR D, but it is the first node on D's path to root R.
Chen & Zhao Expires April 27, 2012 [Page 4]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
1.3. Overview
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+
mLDP node | R2 | | R3 | p2p node
+-----------+ +-----------+
\
+-----------+
| R4 | mLDP node
+-----------+
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
mLDP deployment issue when some nodes without mLDP capability
Figure 1
In the figure above, the R4 nodes finds out that the upstream route
R3 doesn't support mLDP, and there is no other upstream node which R4
can use as the upstream node to go to Root, then this mLDP LSP shown
the picture above can not be setup.
This document specifies a mechanism for deploying the mLDP with the
nodes supporting mLDP completely in the control plane and also in the
forwarding plan mixed with the nodes which dont support the mLDP but
can propagate the notification message toward the root until it finds
the node which supports the mLDP. Both the protocol extensions and
processing procedures are specified in this documents.
Chen & Zhao Expires April 27, 2012 [Page 5]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
2. mLDP deployment through p2p tunnels
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+
mLDP node | R2 | | R3 | p2p node with mLDP
+-----------+ +-----------+ tunnel through support
\
+-----------+
| R4 | mLDP node
+-----------+
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
mLDP deployment through p2p tunnels
Figure 2
In the figure above, when the R4 find out that the upstream route R3
support the mLDP in a p2p tunneled mode, and the R4 sends out the
lapping mapping in a p2p tunnel format, and when the R3 receives this
label mapping message, it will pass up this message to is upstream
router R1. When R1 receives this able mapping message, it will setup
one p2p tunnels which will make the R4 to chose R1 as the next hop to
root for mLDP LSP setup.
Chen & Zhao Expires April 27, 2012 [Page 6]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+
mLDP node | R2 | | R3 | mLDP node
+-----------+ +-----------+
\
+-----------+
| R4 | p2p node with mLDP
+-----------+ tunnel through support
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
mLDP deployment through p2p tunnels for branch node
Figure 3
In the figure above, when the R6 and find out that the upstream
router R4 supports the mLDP in a p2p tunneled mode, and the R4 is
already in the tunnel mode for the mLDP LSP, then R6 will setup
another p2p tunnel between R6 and R3. In this case, R3 will become
the branch node for this mLDP LSP, where the outgoing two branches
are implemented using two p2p tunnels.
2.1. The signaling procedures for deploying mLDP through p2p tunnels
o If LSR D is setting up the MP-LSP <R, X>, D finds out that the
direct connected "upstream LSR" for <R, X> is not supporting mLDP.
o The node D find the upstream node supporting mLDP in p2p
tunneling-through mode capability from the upstream node for mLDP
capability advertisement.
o The node D send an notification message to this upstream node with
its local LSR-ID and mLDP LSP's root node IP address.
o The next hop node sends an notification message to its upstream
node until it reaches the node which support the full mLDP
capability.
o The fist node which has mLDP full capability receives this
notification will setup LDP target LDP sessions with the the node
D identified by the LSR-ID in the notification message. And at
the same time, this first node tells that the node D identified by
Chen & Zhao Expires April 27, 2012 [Page 7]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
the LSR-ID to chose this first node as the upstream router for the
mLDP LSP setup.
o Once the node with the LSR-ID receives this notification from the
first node, it will setup the mLDP lsp as its upstream node to the
root of the mLDP.
2.2. Protocol extensions for deploying mLDP through p2p tunnels
A new type of LDP MP Status Value Element is introduced, for
notifying upstream LSRs and about the LSR-ID and the root of the
mLDP. The MP status element can use what defined in the draft of
draft-mpls-ldp-p2mp-15 by adding two more element types, one of them
is used to identify the root node address of the mLDP and another is
used for identifying the LSR which needs the p2p tunnel to setup the
mLDP lsp. It is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 | Length |capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mLDP LSP Through P2P Tunnel Status Code for LSR-ID
Figure 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 | Length |capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| root-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mLDP LSP Through P2P Tunnel Status Code for root address
Figure 5
Chen & Zhao Expires April 27, 2012 [Page 8]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
3. Acknowledgements
We would like to thank authors of draft-ietf-mpls-mp-ldp-reqs and the
authors of draft-ietf-mpls-ldp-multi-topology from which some text of
this document has been inspired.
4. IANA Considerations
This memo includes the following requests to IANA:
o mLDP P2P Encapsulation type for LDP MP Status Value Element.
5. Security Considerations
The same security considerations apply as for the base LDP
specification, as described in [RFC5036].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC6348] Le Roux, JL. and T. Morin, "Requirements for Point-to-
Multipoint Extensions to the Label Distribution Protocol",
RFC 6348, September 2011.
[I-D.ietf-mpls-ldp-p2mp]
Minei, I., Wijnands, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-15 (work in progress),
August 2011.
[I-D.ietf-mpls-ldp-multi-topology]
Chen & Zhao Expires April 27, 2012 [Page 9]
Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011
Zhao, Q., Fang, L., Zhou, C., Li, L., So, N., and R.
Torvi, "LDP Extension for Multi Topology Support",
draft-ietf-mpls-ldp-multi-topology-00 (work in progress),
October 2011.
6.2. Informative References
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
Authors' Addresses
Emily Chen
Huawei Technology
2330 Central Expressway
Santa Clara, CA 95050
US
Email: emily.chenying@huawei.com
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Chen & Zhao Expires April 27, 2012 [Page 10]
