Internet DRAFT - draft-chen-mpls-mldp-deployment-via-p2p-tunnels
draft-chen-mpls-mldp-deployment-via-p2p-tunnels
Network Working Group Emily Chen
Internet-Draft Quintin Zhao
Intended status: Standards Track Huawei Technology
Expires: January 14, 2013 July 13, 2012
Deploying mLDP Through P2P LSP Tunnels
draft-chen-mpls-mldp-deployment-via-p2p-tunnels-01.txt
Abstract
The existing specification for Multipoint Label Distribution Protocol
(mLDP) functionality assumes that a pair of LDP speakers which
support the P2MP/MP2MP capability are directly connected, or they can
reach each other through targeted LDP session and transparent
tunnel(s). However, the real deployment may not satisfy these
assumptions, especially in the case where the targeted LDP session
and the transparent tunnel(s) have to be pre-established. This
document provides an automatic solution for finding the nearest
upstream node which supports the LDP P2MP/MP2MP along the path from
the current node to the root node, and triggering the targeted LDP
session and transparent tunnel(s) when needed.
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 January 14, 2013.
Copyright Notice
Copyright (c) 2012 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 January 14, 2013 [Page 1]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
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 January 14, 2013 [Page 2]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. mLDP Deployment Through Transparent Tunnels . . . . . . . . . 5
2.1. Signaling Procedures . . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 7
3. mLDP Tunnel Through Capability . . . . . . . . . . . . . . . . 8
4. Handling Route Change Or Failure Event . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Chen & Zhao Expires January 14, 2013 [Page 3]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
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
In practical world, it is extremely hard to synchronously upgrade all
the nodes in a huge network, especially upgrading all the hardware at
the same time. Thus, unless users choose to deploy mLDP by building
a completely new network, otherwise there must be a migration period
from non-mLDP to mLDP capable. During this period, in order to setup
Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and
Multipoint-to-Multipoint (MP2MP) LSPs through the non-mLDP node(s), a
common solution is to make mLDP LSPs going through targeted LDP
sessions and transparent tunnels.
The motivation of this draft is to trigger such kind of mLDP LSP
automatically, so that several benefits can be brought in. First of
all, the manual configuration of the targeted LDP sessions and
transparent tunnels can be waived, correspondingly the network
operation cost can be reduced. Secondly, users don't need to worry
about traffic lost, because no matter whether the necessary targeted
LDP sessions and transparent tunnels are correctly predicted and pre-
configured, they will be automatically triggered when needed.
Besides, because the targeted LDP sessions and transparent tunnels
are built on demand, the resource consumption of system can be
minimal.
1.3. Overview
As specified by [RFC6388], mLDP Label Mapping message would be
stopped when there is no mLDP-capable upstream node. Take the
following scenario as an example, where the R4 node finds out that
its upstream node R3 doesn't support mLDP, and there is no other node
which R4 can use as its upstream node towards Root node, then this
mLDP LSP establishment would fail.
Chen & Zhao Expires January 14, 2013 [Page 4]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+
mLDP node | R2 | | R3 | non-mLDP node
+-----------+ +-----------+
\
+-----------+
| R4 | mLDP node
+-----------+
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
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 do not support the mLDP
but can propagate the mLDP mapping 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.
2. mLDP Deployment Through Transparent Tunnels
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+ non-mLDP node with mLDP
mLDP node | R2 | | R3 | Tunnel Through capability
+-----------+ +-----------+
\
+-----------+
| R4 | mLDP node
+-----------+
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
mLDP Deployment Through Transparent Tunnels
Chen & Zhao Expires January 14, 2013 [Page 5]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
Figure 1
In the figure above, when the R4 finds out that the upstream router
R3 doesn't support mLDP completely but it supports the mLDP Tunnel
Through capability, R4 will send out a notification message with its
LSR-ID. When the R3 receives this notification message, it will
propagate the notification message to is upstream router until
arriving the nearest mLDP capable router, such as R1 in this case.
When R1 receives the notification message, it will trigger the
establishment of targeted LDP session and transparent tunnel to R4.
When finished, R1 will notify R4 to consider it as an upstream
router. Then mLDP advertisement is able to continue.
+------------+
| R1 | mLDP node
+------------+
/ \
+-----------+ +-----------+
mLDP node | R2 | | R3 | mLDP node
+-----------+ +-----------+
\
+-----------+ non-mLDP node with mLDP
| R4 | Tunnel Through capability
+-----------+
/ \
+-----------+ +-----------+
mLDP node | R5 | | R6 | mLDP node
+-----------+ +-----------+
mLDP Deployment Through Transparent Tunnels for Branch Node
Figure 2
In the figure above, assume that R5 has already setup targeted LDP
session and transparent tunnel with R3. When the R6 joins this mLDP
LSP and finds out that the upstream router R4 doesn't support mLDP
completely but it supports the mLDP Tunnel Through capability, R6
will trigger another targeted LDP session and transparent 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 by
using two tranparent tunnels.
2.1. Signaling Procedures
Chen & Zhao Expires January 14, 2013 [Page 6]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
o LDP speakers advertise their capabilities in Initialization
message or Capability message.
o Assume that the node D is setting up the MP-LSP <R, X>, D finds
out that the direct connected "upstream LSR" for <R, X> does not
support mLDP, but it supports mLDP Tunnel Through capability.
o The node D sends 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 propagate the notification message to its
upstream node until it reaches the node which supports the full
mLDP capability.
o When the first node which has mLDP full capability receives this
notification, it will trigger LDP target session(s) and
transparent tunnel(s) with the node D identified by the LSR-ID in
the notification message. When finished, this first node will
tell the node D identified by the LSR-ID to chose it as the
upstream router for the mLDP LSP establishment.
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 using the method superficies in
draft-napierala-mpls-targeted-mldp.
2.2. Protocol Extensions
Two new types of LDP MP Status Value Element are defined, following
the MP Status TLV specification in [RFC6388]. One of them is used to
identify the root node address of the mLDP, the other is used for
identifying the LSR which needs the p2p tunnel to setup the mLDP LSP.
Their encoding are 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 (TBD) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen & Zhao Expires January 14, 2013 [Page 7]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
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 2 (TBD) | Length |C|S| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Capability (C) Flag : 0 = Setting up P2MP LSP
1 = Setting up MP2MP LSP
Signaling (S) Flag : 0 = Advertising the mLDP LSP
1 = Withdrawing the mLDP LSP
3. mLDP Tunnel Through Capability
The mLDP Tunnel Through Capability is advertised among the LDP peers.
The encoding of mLDP Tunnel Through Capability Parameter TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| mLDP Tunnel Through (TBD) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
If one router does not received the mLDP Tunnel Through Capability
advertisement from its neighbor, it should not send the mLDP Tunnel
Through related messages to this neighbor. If one router receives
the mLDP capability annoucement with the mLDP Tunnel Through
capbility, it will silently ignore the mLDP Tunnel Through capability
and consider the sender supports fully mLDP capability. Also if the
router has not advertised the mLDP Tunnel Through Capability, and it
receives the mLDP Tunnel Through related messages, then the receiver
of the message will treat this error as same as it treats for other
unrecognized messages.
4. Handling Route Change Or Failure Event
Assume that the targeted LDP session between the two LSRs with the
Chen & Zhao Expires January 14, 2013 [Page 8]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
mLDP capabilities is established, if there is a route change event
and as the result of this, the downstream router of these two LSR
will have a new upstream router to the root for a specific mLDP LSP,
then the downstream router will treat this similar as the normal re-
route cases. If there is no Make Before Break (MBB) supported, then
the downstream router will delete the LSP setup through targeted
session, then delete the useless targeted session and transparent
tunnel(s). If there is MBB deployed, then the downstream router will
setup the new LSP first and then delete the existing LSP using the
MBB procedures.
If the route from mLDP node to Root node doesn't change, but the
route from the lightweight mLDP node to Root node changes, this
lightweight mLDP node needs to withdraw the previous notification and
advertise a new one to the new upstream node.
5. Acknowledgements
We would like to thank authors of draft-ietf-mpls-mp-ldp-reqs and the
authors of draft-napierala-mpls-targeted-mldp from which some text of
this document has been inspired.
6. IANA Considerations
This memo includes the following requests to IANA:
o mLDP Tunnel Through Capability.
o mLDP LSP Through Transparent Tunnel Status Code for LSR
Identifier.
o mLDP LSP Through Transparent Tunnel Status Code for Root IP
Address.
7. Security Considerations
The same security considerations apply as for the base LDP
specification, as described in [RFC5036].
8. References
Chen & Zhao Expires January 14, 2013 [Page 9]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
8.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.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
8.2. Informative References
[I-D.napierala-mpls-targeted-mldp]
Napierala, M. and E. Rosen, "Using LDP Multipoint
Extensions on Targeted LDP Sessions",
draft-napierala-mpls-targeted-mldp-02 (work in progress),
October 2011.
Authors' Addresses
Emily Chen
Huawei Technology
2330 Central Expressway
Santa Clara, CA 95050
US
Email: emily.chenying@huawei.com
Chen & Zhao Expires January 14, 2013 [Page 10]
Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Chen & Zhao Expires January 14, 2013 [Page 11]
