draft-ietf-mpls-ldp-dod-05.txt   draft-ietf-mpls-ldp-dod-06.txt 
Network Working Group T. Beckhaus Network Working Group T. Beckhaus
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track B. Decraene Intended status: Standards Track B. Decraene
Expires: August 29, 2013 France Telecom Expires: November 11, 2013 France Telecom
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz M. Konstantynowicz
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
February 25, 2013 May 10, 2013
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-05 draft-ietf-mpls-ldp-dod-06
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of using standardized IP/MPLS protocols. One of the key goals of
Seamless MPLS is to meet requirements specific to access, including Seamless MPLS is to meet requirements specific to access, including
high number of devices, their position in network topology and their high number of devices, their position in network topology and their
compute and memory constraints that limit the amount of state access compute and memory constraints that limit the amount of state access
devices can hold.This can be achieved with LDP Downstream-on-Demand devices can hold.This can be achieved with LDP Downstream-on-Demand
(LDP DoD) label advertisement. This document describes LDP DoD use (LDP DoD) label advertisement. This document describes LDP DoD use
cases and lists required LDP DoD procedures in the context of cases and lists required LDP DoD procedures in the context of
Seamless MPLS design. Seamless MPLS design.
In addition, a new optional TLV type in the LDP label request message In addition, a new optional TLV type in the LDP Label Request message
is defined for fast-up convergence. is defined for fast-up convergence.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on November 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . 4
2.1. Access Topologies with Static Routing . . . . . . . . . . 6 2.1. Access Topologies with Static Routing . . . . . . . . . . 5
2.2. Access Topologies with Access IGP . . . . . . . . . . . . 8 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 8
3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10
3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 10 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 10
3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 12 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11
3.2. Service Provisioning and Activation . . . . . . . . . . . 12 3.2. Service Provisioning and Activation . . . . . . . . . . . 12
3.3. Service Changes and Decommissioning . . . . . . . . . . . 15 3.3. Service Changes and Decommissioning . . . . . . . . . . . 15
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 18 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 18
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 19 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 19
4.1. LDP Label Distribution Control and Retention Modes . . . . 19 4.1. LDP Label Distribution Control and Retention Modes . . . 19
4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21
4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21 4.3. Label Request Procedures . . . . . . . . . . . . . . . . 22
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 22
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 23
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23
4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 23 4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 25
4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 25 4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 25
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 26 5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 25
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 27
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . 28
6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 7.1.1. Access to network packet flow direction . . . . . . . 28
6.1.1. Access to network packet flow direction . . . . . . . 28 7.1.2. Network to access packet flow direction . . . . . . . 28
6.1.2. Network to access packet flow direction . . . . . . . 28 7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29
6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 7.3. Control Plane Security . . . . . . . . . . . . . . . . . 30
6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 7.4. Network Node Security . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single
IP/MPLS network to scale over core, metro and access parts of a large IP/MPLS network to scale over core, metro and access parts of a large
packet network infrastructure using standardized IP/MPLS protocols. packet network infrastructure using standardized IP/MPLS protocols.
One of the key goals of Seamless MPLS is to meet requirements One of the key goals of Seamless MPLS is to meet requirements
specific to access, including high number of devices, their position specific to access, including high number of devices, their position
in network topology and their compute and memory constraints that in network topology and their compute and memory constraints that
limit the amount of state access devices can hold. limit the amount of state access devices can hold.
skipping to change at page 5, line 17 skipping to change at page 4, line 36
connectivity for the provisioned services. And although filters can connectivity for the provisioned services. And although filters can
be applied to those LDP DU labels advertisements, it is not seen as a be applied to those LDP DU labels advertisements, it is not seen as a
suitable tool to facilitate any-to-any AN-driven connectivity between suitable tool to facilitate any-to-any AN-driven connectivity between
access and the rest of the MPLS network. access and the rest of the MPLS network.
This document describes an access node driven "subscription model" This document describes an access node driven "subscription model"
for label distribution in the access. The approach relies on the for label distribution in the access. The approach relies on the
standard LDP Downstream-on-Demand (LDP DoD) label advertisements as standard LDP Downstream-on-Demand (LDP DoD) label advertisements as
specified in [RFC5036]. LDP DoD enables on-demand label distribution specified in [RFC5036]. LDP DoD enables on-demand label distribution
ensuring that only required labels are requested, provided and ensuring that only required labels are requested, provided and
installed. installed. Procedures described in this document are equally
applicable to LDP IPv4 and IPv6 address families. For simplicity the
document provides examples based on LDP IPv4 address family.
The following sections describe a set of reference access topologies The following sections describe a set of reference access topologies
considered for LDP DoD usage and their associated IP routing considered for LDP DoD usage and their associated IP routing
configurations, followed by LDP DoD use cases and LDP DoD procedures configurations, followed by LDP DoD use cases and LDP DoD procedures
in the context of Seamless MPLS design. in the context of Seamless MPLS design.
2. Reference Topologies 2. Reference Topologies
LDP DoD use cases are described in the context of a generic reference LDP DoD use cases are described in the context of a generic reference
end-to-end network topology based on Seamless MPLS design end-to-end network topology based on Seamless MPLS design
skipping to change at page 5, line 32 skipping to change at page 5, line 4
in the context of Seamless MPLS design. in the context of Seamless MPLS design.
2. Reference Topologies 2. Reference Topologies
LDP DoD use cases are described in the context of a generic reference LDP DoD use cases are described in the context of a generic reference
end-to-end network topology based on Seamless MPLS design end-to-end network topology based on Seamless MPLS design
[I-D.ietf-mpls-seamless-mpls] shown in Figure 1 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN
+--------+/ +-------+ +-------+ +------+ +------+ +--------+/ +-------+ +-------+ +------+ +------+
| Access | \/ \/ | Access | \/ \/
| Network| /\ /\ | Network| /\ /\
+--------+ +-------+ +-------+ +------+ +------+ +--------+ +-------+ +-------+ +------+ +------+
\---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
static routes static routes
or access IGP ISIS L1 ISIS L2 or access IGP IGP area IGP area
<----Access----><--Aggregation Domain--><----Core-----> <----Access----><--Aggregation Domain--><----Core----->
<------------------------- MPLS ----------------------> <------------------------- MPLS ---------------------->
Figure 1: Seamless MPLS end-to-end reference network topology. Figure 1: Seamless MPLS end-to-end reference network topology.
The access network is either single or dual homed to AGN1x, with The access network is either single or dual homed to AGN1x, with
either a single or multiple parallel links to AGN1x. either a single or multiple parallel links to AGN1x.
Seamless MPLS access network topologies can range from a single- or Seamless MPLS access network topologies can range from a single- or
dual-homed access node to a chain or ring of access nodes, and use dual-homed access node to a chain or ring of access nodes, and use
either static routing or access IGP. The following sections describe either static routing or access IGP ( ISIS or OSPF ). The following
reference access topologies in more detail. sections describe reference access topologies in more detail.
2.1. Access Topologies with Static Routing 2.1. Access Topologies with Static Routing
In most cases access nodes connect to the rest of the network using In most cases access nodes connect to the rest of the network using
very simple topologies. Here static routing is sufficient to provide very simple topologies. Here static routing is sufficient to provide
the required IP connectivity. The following topologies are the required IP connectivity. The following topologies are
considered for use with static routing and LDP DoD: considered for use with static routing and LDP DoD:
a. [I1] topology - a single AN homed to a single AGN. a. [I1] topology - a single AN homed to a single AGN.
skipping to change at page 6, line 28 skipping to change at page 5, line 48
c. [V] topology - a single AN dual-homed to two AGNs. c. [V] topology - a single AN dual-homed to two AGNs.
d. [U2] topology - two ANs dual-homed to two AGNs. d. [U2] topology - two ANs dual-homed to two AGNs.
e. [Y] topology - multiple ANs daisy-chained to two AGNs. e. [Y] topology - multiple ANs daisy-chained to two AGNs.
The reference static routing and LDP configuration for [V] access The reference static routing and LDP configuration for [V] access
topology is shown in Figure 2. The same static routing and LDP topology is shown in Figure 2. The same static routing and LDP
configuration also applies to [I1] topology. configuration also applies to [I1] topology.
+----+ +-------+ +----+ +-------+
|AN1 +------------------------+ AGN11 +------- |AN1 +------------------------+ AGN11 +-------
| +-------\ /-----------+ +-\ / | +-------\ /-----------+ +-\ /
+----+ \ / +-------+ \ / +----+ \ / +-------+ \ /
\/ \/ \/ \/
/\ /\ /\ /\
+----+ / \ +-------+ / \ +----+ / \ +-------+ / \
|AN2 +-------/ \-----------+ AGN12 +-/ \ |AN2 +-------/ \-----------+ AGN12 +-/ \
| +------------------------+ +------- | +------------------------+ +-------
+----+ +-------+ +----+ +-------+
--(u)-> <-(d)-- --(u)-> <-(d)--
<----- static routing -------> <--- ISIS ---> <----- static routing -------> <--- IGP ---->
<-- LDP DU --> <-- LDP DU -->
<--------- LDP DoD ----------> <-- BGP LU --> <--------- LDP DoD ----------> <-- BGP LU -->
(u) static routes: 0/0 default, (optional) /32 or /128 destinations (u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: /32 or /128 AN loopbacks (d) static routes: AN loopbacks
Figure 2: [V] access topology with static routes. Figure 2: [V] access topology with static routes.
In line with the Seamless MPLS design, static routes configured on In line with the Seamless MPLS design, static routes configured on
AGN1x and pointing towards the access network are redistributed in AGN1x and pointing towards the access network are redistributed in
either ISIS or BGP labeled unicast (BGP-LU) [RFC3107]. either IGP or BGP labeled unicast (BGP-LU) [RFC3107].
The reference static routing and LDP configuration for [U2] access The reference static routing and LDP configuration for [U2] access
topology is shown in Figure 3. topology is shown in Figure 3.
+----+ +-------+ +----+ +-------+
(d1) |AN1 +------------------------+ AGN11 +------- (d1) |AN1 +------------------------+ AGN11 +-------
| | + + +-\ / | | + + +-\ /
v +-+--+ +-------+ \ / v +-+--+ +-------+ \ /
| \/ | \/
| /\ | /\
^ +-+--+ +-------+ / \ ^ +-+--+ +-------+ / \
| |AN2 + + AGN12 +-/ \ | |AN2 + + AGN12 +-/ \
(d2) | +------------------------+ +------- (d2) | +------------------------+ +-------
+----+ +-------+ +----+ +-------+
--(u)-> <-(d)-- --(u)-> <-(d)--
<------- static routing --------> <--- ISIS ---> <------- static routing --------> <--- IGP ---->
<-- LDP DU --> <-- LDP DU -->
<----------- LDP DoD -----------> <-- BGP LU --> <----------- LDP DoD -----------> <-- BGP LU -->
(u) static route 0/0 default (/32 or /128 destinations optional) (u) static route 0/0 default, (optional) /32 routes
(d) static route for /32 or /128 AN loopbacks (d) static route for AN loopbacks
(d1) static route for /32 or /128 AN2 loopback and 0/0 default with lower preference (d1) static route for AN2 loopback and 0/0 default with
(d2) static route for /32 or /128 AN1 loopback and 0/0 default with lower preference lower preference
(d2) static route for AN1 loopback and 0/0 default with
lower preference
Figure 3: [U2] access topology with static routes. Figure 3: [U2] access topology with static routes.
The reference static routing and LDP configuration for [Y] access The reference static routing and LDP configuration for [Y] access
topology is shown in Figure 4. The same static routing and LDP topology is shown in Figure 4. The same static routing and LDP
configuration also applies to [I] topology. configuration also applies to [I] topology.
+-------+ +-------+
| |---/ | |---/
/----+ AGN11 | /----+ AGN11 |
+----+ +----+ +----+ / | |---\ +----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+ | | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 | |ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+ | | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/ +----+ +----+ +----+ \ | |---/
\----+ AGN12 | \----+ AGN12 |
<-(d2)-- <-(d1)-- | |---\ <-(d2)-- <-(d1)-- | |---\
--(u)-> --(u)-> --(u)-> +-------+ --(u)-> --(u)-> --(u)-> +-------+
<-(d)-- <-(d)--
<------- static routing -------> <--- ISIS ---> <------- static routing -------> <--- IGP ---->
<-- LDP DU --> <-- LDP DU -->
<---------- LDP DoD -----------> <-- BGP LU --> <---------- LDP DoD -----------> <-- BGP LU -->
(u) static routes: 0/0 default, (optional) /32 or /128 destinations (u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: /32 or /128 AN loopbacks [1..n] (d) static routes: AN loopbacks [1..n]
(d1) static routes: /32 or /128 AN loopbacks [2..n] (d1) static routes: AN loopbacks [2..n]
(d2) static routes: /32 or /128 AN loopbacks [3..n] (d2) static routes: AN loopbacks [3..n]
Figure 4: [Y] access topology with static routes. Figure 4: [Y] access topology with static routes.
Note that in all of the above topologies parallel ECMP (or L2 LAG) Note that in all of the above topologies parallel ECMP (or L2 LAG)
links can be used between the nodes. links can be used between the nodes.
ANs support Inter-area LDP [RFC5283] in order to use the IP default ANs support Inter-area LDP [RFC5283] in order to use the IP default
route to match the LDP FEC advertised by AGN1x and other ANs. route to match the LDP FEC advertised by AGN1x and other ANs.
2.2. Access Topologies with Access IGP 2.2. Access Topologies with Access IGP
skipping to change at page 9, line 6 skipping to change at page 9, line 5
a. [U] topology - multiple ANs chained in an open ring and dual- a. [U] topology - multiple ANs chained in an open ring and dual-
homed to two AGNs. homed to two AGNs.
b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two
AGNs. AGNs.
The reference access IGP and LDP configuration for [U] access The reference access IGP and LDP configuration for [U] access
topology is shown in Figure 5. topology is shown in Figure 5.
+-------+ +-------+
+-----+ +-----+ +----+ | +---/ +-----+ +-----+ +----+ | +---/
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 | | AN3 |---| AN2 |---|AN1 +-----+ AGN11 |
+-----+ +-----+ +----+ | +---\ +-----+ +-----+ +----+ | +---\
. +-------+ . +-------+
. .
. +-------+ . +-------+
+-----+ +-----+ +----+ | +---/ +-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 | |ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\ +-----+ +-----+ +----+ | +---\
+-------+ +-------+
<---------- access IGP ------------> <--- ISIS ---> <---------- access IGP ------------> <--- IGP ---->
<-- LDP DU --> <-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU --> <------------ LDP DoD -------------> <-- BGP LU -->
Figure 5: [U] access topology with access IGP. Figure 5: [U] access topology with access IGP.
The reference access IGP and LDP configuration for [Y] access The reference access IGP and LDP configuration for [Y] access
topology is shown in Figure 6. topology is shown in Figure 6.
+-------+ +-------+
| |---/ | |---/
/----+ AGN11 |2 /----+ AGN11 |2
+----+ +----+ +----+ / | |---\ +----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+ | | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 | |ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+ | | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/ +----+ +----+ +----+ \ | |---/
\----+ AGN12 | \----+ AGN12 |
| |---\ | |---\
+-------+ +-------+
<---------- access IGP ------------> <--- ISIS ---> <---------- access IGP ------------> <--- IGP ---->
<-- LDP DU --> <-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU --> <------------ LDP DoD -------------> <-- BGP LU -->
Figure 6: [Y] access topology with access IGP. Figure 6: [Y] access topology with access IGP.
Note that in all of the above topologies parallel ECMP (or L2 LAG) Note that in all of the above topologies parallel ECMP (or L2 LAG)
links can be used between the nodes. links can be used between the nodes.
In both of the above topologies, ANs (ANn ... AN1) and AGN1x share In both of the above topologies, ANs (ANn ... AN1) and AGN1x share
the access IGP and advertise their IPv4 and IPv6 loopbacks and link the access IGP and advertise their IPv4 and IPv6 loopbacks and link
addresses. AGN1x advertise a default route into the access IGP. addresses. AGN1x advertise a default route into the access IGP.
ANs support Inter-area LDP [RFC5283] in order to use the IP default ANs support Inter-area LDP [RFC5283] in order to use the IP default
route for matching the LDP FECs advertised by AGN1x or other ANs. route for matching the LDP FECs advertised by AGN1x or other ANs.
3. LDP DoD Use Cases 3. LDP DoD Use Cases
LDP DoD operation is driven by Seamless MPLS use cases. This section LDP DoD use cases described in this document are based on the
illustrates these use cases focusing on services provisioned on the Seamless MPLS scenarios listed in Seamless MPLS design
access nodes and clarifies expected LDP DoD operation on the AN and [I-D.ietf-mpls-seamless-mpls]. This section illustrates these use
AGN1x devices. Two representative service types are used to cases focusing on services provisioned on the access nodes and
illustrate the service use cases: MPLS PWE3 [RFC4447] and BGP/MPLS clarifies expected LDP DoD operation on the AN and AGN1x devices.
IPVPN [RFC4364]. Two representative service types are used to illustrate the service
use cases: MPLS PWE3 [RFC4447] and BGP/MPLS IPVPN [RFC4364].
Described LDP DoD operations apply equally to all reference access Described LDP DoD operations apply equally to all reference access
topologies described in Section 2. Operations that are specific to topologies described in Section 2. Operations that are specific to
certain access topologies are called out explicitly. certain access topologies are called out explicitly.
References to upstream and downstream nodes are made in line with the References to upstream and downstream nodes are made in line with the
definition of upstream and downstream LSR [RFC3031]. definition of upstream and downstream LSR [RFC3031].
This document is focusing on IPv4 LDP DoD procedures. Similar LDP DoD procedures follow the LDP specification [RFC5036], and are
procedures will apply to IPv6 LDP DoD [I-D.ietf-mpls-ldp-ipv6]. equally applicable to LDP IPv4 and IPv6 address families. For
simplicity examples are provided for LDP IPv4 address family only.
3.1. Initial Network Setup 3.1. Initial Network Setup
An access node is commissioned without any services provisioned on An access node is commissioned without any services provisioned on
it. The AN may request labels for loopback addresses of any AN, AGN it. The AN may request labels for loopback addresses of any AN, AGN
or other nodes within Seamless MPLS network for operational and or other nodes within Seamless MPLS network for operational and
management purposes. It is assumed that AGN1x has required IP/MPLS management purposes. It is assumed that AGN1x has required IP/MPLS
configuration for network-side connectivity in line with Seamless configuration for network-side connectivity in line with Seamless
MPLS design [I-D.ietf-mpls-seamless-mpls]. MPLS design [I-D.ietf-mpls-seamless-mpls].
skipping to change at page 10, line 49 skipping to change at page 10, line 48
3.1.1. AN with Static Routing 3.1.1. AN with Static Routing
If access static routing is used, ANs are provisioned with the If access static routing is used, ANs are provisioned with the
following static IP routing entries (topology references from following static IP routing entries (topology references from
Section 2 are listed in square brackets): Section 2 are listed in square brackets):
a. [I1, V, U2] - Static default route 0/0 pointing to links a. [I1, V, U2] - Static default route 0/0 pointing to links
connected to AGN1x. Requires support for Inter-area LDP connected to AGN1x. Requires support for Inter-area LDP
[RFC5283]. [RFC5283].
b. [U2] - Static /32 or /128 routes pointing to the other AN. Lower b. [U2] - Static /32 routes pointing to the other AN. Lower
preference static default route 0/0 pointing to links connected preference static default route 0/0 pointing to links connected
to the other AN. Requires support for Inter-area LDP [RFC5283]. to the other AN. Requires support for Inter-area LDP [RFC5283].
c. [I, Y] - Static default route 0/0 pointing to links leading c. [I, Y] - Static default route 0/0 pointing to links leading
towards AGN1x. Requires support for Inter-area LDP [RFC5283]. towards AGN1x. Requires support for Inter-area LDP [RFC5283].
d. [I, Y] - Static /32 or /128 routes to all ANs in the daisy-chain d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing
pointing to links towards those ANs. to links towards those ANs.
e. [I1, V, U2] - Optional - Static /32 or /128 routes for specific e. [I1, V, U2] - Optional - Static /32 routes for specific nodes
nodes within Seamless MPLS network, pointing to links connected within Seamless MPLS network, pointing to links connected to
to AGN1x. AGN1x.
f. [I, Y] - Optional - Static /32 or /128 routes for specific nodes f. [I, Y] - Optional - Static /32 routes for specific nodes within
within the Seamless MPLS network, pointing to links leading the Seamless MPLS network, pointing to links leading towards
towards AGN1x. AGN1x.
Upstream AN/AGN1x should request labels over LDP DoD session(s) from Upstream AN/AGN1x should request labels over LDP DoD session(s) from
downstream AN/AGN1x for configured static routes if those static downstream AN/AGN1x for configured static routes if those static
routes are configured with LDP DoD request policy and if they are routes are configured with LDP DoD request policy and if they are
pointing to a next-hop selected by routing. It is expected that all pointing to a next-hop selected by routing. It is expected that all
configured /32 and /128 static routes to be used for LDP DoD are configured /32 static routes to be used for LDP DoD are configured
configured with such policy on AN/AGN1x. with such policy on AN/AGN1x.
Downstream AN/AGN1x should respond to the label request from the Downstream AN/AGN1x should respond to the Label Request from the
upstream AN/AGN1x with a label mapping if requested route is present upstream AN/AGN1x with a Label Mapping if requested route is present
in its RIB, and there is a valid label binding from its downstream or in its RIB, and there is a valid label binding from its downstream or
it is the egress node. In such case downstream AN/AGN1x must install it is the egress node. In such case downstream AN/AGN1x must install
the advertised label as an incoming label in its label table (LIB) the advertised label as an incoming label in its label table (LIB)
and its forwarding table (LFIB). Upstream AN/AGN1x must also install and its forwarding table (LFIB). Upstream AN/AGN1x must also install
the received label as an outgoing label in their LIB and LFIB. If the received label as an outgoing label in their LIB and LFIB. If
the downstream AN/AGN1x does have the route present in its RIB, but the downstream AN/AGN1x does have the route present in its RIB, but
does not have a valid label binding from its downstream, it should does not have a valid label binding from its downstream, it should
forward the request to its downstream. forward the request to its downstream.
In order to facilitate ECMP and IPFRR LFA local-repair, the upstream In order to facilitate ECMP and IPFRR LFA local-repair, the upstream
skipping to change at page 12, line 18 skipping to change at page 12, line 15
access IGP with configured metrics. AGN1x advertise a default route access IGP with configured metrics. AGN1x advertise a default route
over the access IGP. over the access IGP.
Routers request labels over LDP DoD session(s) according to their Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per needs for MPLS connectivity (LSPs). In particular if AGNs, as per
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute
routes from the IGP into BGP labeled unicast [RFC3107], they should routes from the IGP into BGP labeled unicast [RFC3107], they should
request labels over LDP DoD session(s) for those routes. request labels over LDP DoD session(s) for those routes.
Identically to the static route case, downstream AN/AGN1x should Identically to the static route case, downstream AN/AGN1x should
respond to the label request from the upstream AN/AGN1x with a label respond to the Label Request from the upstream AN/AGN1x with a Label
mapping (if the requested route is present in its RIB, and there is a Mapping (if the requested route is present in its RIB, and there is a
valid label binding from its downstream), and must install the valid label binding from its downstream), and must install the
advertised label as an incoming label in its LIB and LFIB. Upstream advertised label as an incoming label in its LIB and LFIB. Upstream
AN/AGN1x must also install the received label as an outgoing label in AN/AGN1x must also install the received label as an outgoing label in
their LIB and LFIB. their LIB and LFIB.
Identically to the static route case, in order to facilitate ECMP and Identically to the static route case, in order to facilitate ECMP and
IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD
label requests to alternate next-hops per its RIB, and install label requests to alternate next-hops per its RIB, and install
received labels as alternate entries in its LIB and LFIB. received labels as alternate entries in its LIB and LFIB.
skipping to change at page 14, line 17 skipping to change at page 14, line 16
have been listed. Other non IP/MPLS connectivity operations that may have been listed. Other non IP/MPLS connectivity operations that may
be required for successful service provisioning are out of scope in be required for successful service provisioning are out of scope in
this document. this document.
To establish an LSP for destination /32 FEC for any of the above To establish an LSP for destination /32 FEC for any of the above
services, AN* looks up its local routing table for a matching route, services, AN* looks up its local routing table for a matching route,
selects the best next-hop(s) and associated outgoing link(s). selects the best next-hop(s) and associated outgoing link(s).
If a label for this /32 FEC is not already installed based on the If a label for this /32 FEC is not already installed based on the
configured static route with LDP DoD request policy or access IGP RIB configured static route with LDP DoD request policy or access IGP RIB
entry, AN* must send an LDP DoD label mapping request. Downstream entry, AN* must send an LDP DoD Label Mapping request. Downstream AN
AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and /AGN1x LSR(s) checks its RIB for presence of the requested /32 and
associated valid outgoing label binding, and if both are present, associated valid outgoing label binding, and if both are present,
replies with its label for this FEC and installs this label as replies with its label for this FEC and installs this label as
incoming in its LIB and LFIB. Upon receiving the label mapping the incoming in its LIB and LFIB. Upon receiving the Label Mapping the
AN* must accept this label based on the exact route match of AN* must accept this label based on the exact route match of
advertised FEC and route entry in its RIB or based on the longest advertised FEC and route entry in its RIB or based on the longest
match in line with Inter-area LDP [RFC5283]. If the AN* accepts the match in line with Inter-area LDP [RFC5283]. If the AN* accepts the
label it must install it as an outgoing label in its LIB and LFIB. label it must install it as an outgoing label in its LIB and LFIB.
In access topologies [V] and [Y], if AN* is dual homed to two AGN1x In access topologies [V] and [Y], if AN* is dual homed to two AGN1x
and routing entries for these AGN1x are configured as equal cost and routing entries for these AGN1x are configured as equal cost
paths, AN* must send LDP DoD label requests to both AGN1x devices and paths, AN* must send LDP DoD label requests to both AGN1x devices and
install all received labels in its LIB and LFIB. install all received labels in its LIB and LFIB.
skipping to change at page 16, line 7 skipping to change at page 16, line 7
In general, unless the service failure event modifies required MPLS In general, unless the service failure event modifies required MPLS
connectivity, there should be no impact on the LDP DoD operation. connectivity, there should be no impact on the LDP DoD operation.
If the service failure event does modify the required MPLS If the service failure event does modify the required MPLS
connectivity, LDP DoD operations apply as described in Section 3.2 connectivity, LDP DoD operations apply as described in Section 3.2
and Section 3.3. and Section 3.3.
3.5. Network Transport Failure 3.5. Network Transport Failure
A number of different network events can impact services on AN*. The A number of different network events can impact services on AN*. The
following sections describe network event types that impact LDP DoD following sections describe network event types that impact LDP DoD
operation on AN and AGN1x nodes. operation on AN and AGN1x nodes.
3.5.1. General Notes 3.5.1. General Notes
If service on any of the ANs is affected by any network failure and If service on any of the ANs is affected by any network failure and
there is no network redundancy, the service must go into a failure there is no network redundancy, the service must go into a failure
state. When the network failure is recovered from, the service must state. When the network failure is recovered from, the service must
be re-established automatically. be re-established automatically.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
Adjacent AN/AGN1x nodes remove all routes pointing to the failed Adjacent AN/AGN1x nodes remove all routes pointing to the failed
link(s) from their RIB tables (including /32 loopback belonging to link(s) from their RIB tables (including /32 loopback belonging to
the failed AN and any other routes reachable via the failed AN). the failed AN and any other routes reachable via the failed AN).
This in turn triggers the removal of associated outgoing /32 FEC This in turn triggers the removal of associated outgoing /32 FEC
labels from their LIB and LFIB tables. labels from their LIB and LFIB tables.
If access IGP is used, the AN node failure will be propagated via IGP If access IGP is used, the AN node failure will be propagated via IGP
link updates across the access topology. link updates across the access topology.
If a specific /32 FEC(s) is not reachable anymore from those AN/ If a specific /32 FEC(s) is not reachable anymore from those AN/
AGN1x, they must also send LDP label withdraw to their upstream LSRs AGN1x, they must also send LDP Label Withdraw to their upstream LSRs
to notify about the failure, and remove the associated incoming to notify about the failure, and remove the associated incoming
label(s) from their LIB and LFIB tables. Upstream LSRs upon label(s) from their LIB and LFIB tables. Upstream LSRs upon
receiving label withdraw should remove the signaled labels from their receiving Label Withdraw should remove the signaled labels from their
LIB/LFIB tables, and propagate LDP label withdraw across their LIB/LFIB tables, and propagate LDP Label Withdraw across their
upstream LDP DoD sessions. upstream LDP DoD sessions.
In [U] topology there may be an alternative path to routes previously In [U] topology there may be an alternative path to routes previously
reachable via the failed AN node. In this case adjacent AN/AGN1x reachable via the failed AN node. In this case adjacent AN/AGN1x
should invoke local-repair (IPFRR LFA, ECMP) and switchover to should invoke local-repair (IPFRR LFA, ECMP) and switchover to
alternate next-hop to reach those routes. alternate next-hop to reach those routes.
AGN1x gets notified about the AN failure via either access IGP (if AGN1x gets notified about the AN failure via either access IGP (if
used) and/or cascaded LDP DoD label withdraw(s). AGN1x must used) and/or cascaded LDP DoD label withdraw(s). AGN1x must
implement all relevant global-repair IP/MPLS procedures to propagate implement all relevant global-repair IP/MPLS procedures to propagate
skipping to change at page 18, line 4 skipping to change at page 18, line 4
b. [I1, I, Y] - link failed, and there are no ECMP or alternative b. [I1, I, Y] - link failed, and there are no ECMP or alternative
links and paths - nodes on both sides of the failed link must links and paths - nodes on both sides of the failed link must
remove routes pointing to the failed link immediately from the remove routes pointing to the failed link immediately from the
RIB, remove associated labels from their LIB and LFIB tabels, and RIB, remove associated labels from their LIB and LFIB tabels, and
must send LDP label withdraw(s) to their upstream LSRs. must send LDP label withdraw(s) to their upstream LSRs.
c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate
path remains - AN/AGN1x node must stop using the failed link and path remains - AN/AGN1x node must stop using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switchover (local-repair) to the remaining ECMP path
or alternate path. AN/AGN1x must remove affected next-hops and or alternate path. AN/AGN1x must remove affected next-hops and
labels from its tables and invoke LDP label withdraw as per point labels from its tables and invoke LDP Label Withdraw as per point
(a) above. If there is an AGN1x node terminating the failed (a) above. If there is an AGN1x node terminating the failed
link, it must remove routes pointing to the failed link link, it must remove routes pointing to the failed link
immediately from the RIB, remove associated labels from their LIB immediately from the RIB, remove associated labels from their LIB
and LFIB tabels, and must propagate the failure on the network and LFIB tabels, and must propagate the failure on the network
side using BGP-LU and/or core IGP procedures. side using BGP-LU and/or core IGP procedures.
If access IGP is used AN/AGN1x link failure will be propagated via If access IGP is used AN/AGN1x link failure will be propagated via
IGP link updates across the access topology. IGP link updates across the access topology.
LDP DoD will also propagate the link failure by sending label LDP DoD will also propagate the link failure by sending label
withdraws to upstream AN/AGN1x nodes, and label release messages withdraws to upstream AN/AGN1x nodes, and Label Release messages
downstream AN/AGN1x nodes. downstream AN/AGN1x nodes.
3.5.4. AGN Node Failure 3.5.4. AGN Node Failure
AGN1x fails and all links to adjacent access nodes go down. AGN1x fails and all links to adjacent access nodes go down.
Depending on the access topology, following cases apply to the Depending on the access topology, following cases apply to the
network operation after AGN1x node failure (topology references from network operation after AGN1x node failure (topology references from
Section 2 in square brackets): Section 2 in square brackets):
skipping to change at page 18, line 37 skipping to change at page 18, line 37
failure must remove routes pointing to the failed AGN1x node failure must remove routes pointing to the failed AGN1x node
immediately from the RIB, remove associated labels from their LIB immediately from the RIB, remove associated labels from their LIB
and LFIB tabels, and must send LDP label withdraw(s) to their and LFIB tabels, and must send LDP label withdraw(s) to their
upstream LSRs. If access IGP is used, an IGP link update should upstream LSRs. If access IGP is used, an IGP link update should
be sent. be sent.
b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN
adjacent to failed AGN1x must stop using the failed link and adjacent to failed AGN1x must stop using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switchover (local-repair) to the remaining ECMP path
or alternate path. AN must remove affected routes and labels or alternate path. AN must remove affected routes and labels
from its tables and invoke LDP label withdraw as per point (a) from its tables and invoke LDP Label Withdraw as per point (a)
above. above.
Network side procedures for handling AGN1x node failure have been Network side procedures for handling AGN1x node failure have been
described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls].
3.5.5. AGN Network-side Reachability Failure 3.5.5. AGN Network-side Reachability Failure
AGN1x loses network reachability to a specific destination or set of AGN1x loses network reachability to a specific destination or set of
network-side destinations. network-side destinations.
skipping to change at page 19, line 14 skipping to change at page 19, line 14
part of global-repair. In turn ANs should also sent Label Withdraw part of global-repair. In turn ANs should also sent Label Withdraw
messages for affected /32 FECs to their upstream ANs. messages for affected /32 FECs to their upstream ANs.
If access IGP is used, and AGN1x gets completely isolated from the If access IGP is used, and AGN1x gets completely isolated from the
core network, it should stop advertising the default route 0/0 into core network, it should stop advertising the default route 0/0 into
the access IGP. the access IGP.
4. LDP DoD Procedures 4. LDP DoD Procedures
Label Distribution Protocol is specified in [RFC5036], and all LDP Label Distribution Protocol is specified in [RFC5036], and all LDP
Downstream-on-Demand implementations MUST follow [RFC5036] Downstream-on-Demand implementations follow [RFC5036] specification.
specification. This section does not update [RFC5036] procedures, but illustrates
LDP DoD operations in the context of use cases identified in
Section 3 in this document, for information only.
In the MPLS architecture [RFC3031], network traffic flows from In the MPLS architecture [RFC3031], network traffic flows from
upstream to downstream LSR. The use cases in this document rely on upstream to downstream LSR. The use cases in this document rely on
the downstream assignment of labels, where labels are assigned by the the downstream assignment of labels, where labels are assigned by the
downstream LSR and signaled to the upstream LSR as shown in Figure 7. downstream LSR and signaled to the upstream LSR as shown in Figure 7.
+----------+ +------------+ +----------+ +------------+
| upstream | | downstream | | upstream | | downstream |
------+ LSR +------+ LSR +---- ------+ LSR +------+ LSR +----
traffic | | | | address traffic | | | | address
skipping to change at page 19, line 49 skipping to change at page 19, line 51
distribution control, following the definitions in MPLS architecture distribution control, following the definitions in MPLS architecture
[RFC3031]: [RFC3031]:
o Independent mode - an LSR recognizes a particular FEC and makes a o Independent mode - an LSR recognizes a particular FEC and makes a
decision to bind a label to the FEC independently from decision to bind a label to the FEC independently from
distributing that label binding to its label distribution peers. distributing that label binding to its label distribution peers.
A new FEC is recognized whenever a new route becomes valid on the A new FEC is recognized whenever a new route becomes valid on the
LSR. LSR.
o Ordered mode - an LSR needs to bind a label to a particular FEC if o Ordered mode - an LSR needs to bind a label to a particular FEC if
it knows how to forward packets for that FEC ( i.e. it has a route it knows how to forward packets for that FEC ( i.e. it has a
corresponding to that FEC ) and if it has already received at route corresponding to that FEC ) and if it has already received
least one label request message from an upstream LSR. at least one Label Request message from an upstream LSR.
Using independent label distribution control with LDP DoD and access Using independent label distribution control with LDP DoD and access
static routing would prevent the access LSRs from propagating label static routing would prevent the access LSRs from propagating label
binding failure along the access topology, making it impossible for binding failure along the access topology, making it impossible for
upstream LSR to be notified about the downstream failure and for an upstream LSR to be notified about the downstream failure and for an
application using the LSP to switchover to an alternate path, even if application using the LSP to switchover to an alternate path, even if
such a path exists. such a path exists.
LDP protocol specification [RFC5036] defines two modes for label LDP protocol specification [RFC5036] defines two modes for label
retention, following the definitions in MPLS architecture [RFC3031]: retention, following the definitions in MPLS architecture [RFC3031]:
skipping to change at page 21, line 8 skipping to change at page 21, line 14
Note that even though LDP DoD operates in a liberal retention mode, Note that even though LDP DoD operates in a liberal retention mode,
if used with access IGP and if no LFA exists, the LDP DoD will if used with access IGP and if no LFA exists, the LDP DoD will
introduce additional delay in traffic restoration as the labels for introduce additional delay in traffic restoration as the labels for
the new next-hop will get requested only after the access IGP the new next-hop will get requested only after the access IGP
convergence. convergence.
Adhering to the overall design goals of Seamless MPLS Adhering to the overall design goals of Seamless MPLS
[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network
scale without compromising fast service restoration, all access LSRs scale without compromising fast service restoration, all access LSRs
(AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: (AN and AGN1x nodes) use LDP DoD advertisement mode with:
o Ordered label distribution control - enables propagation of label o Ordered label distribution control - enables propagation of label
binding failure within the access topology. binding failure within the access topology.
o Liberal label retention - enables pre-programming of alternate o Liberal label retention - enables pre-programming of alternate
next-hops with associated FEC labels. next-hops with associated FEC labels.
In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an
access ABR connecting access and metro domains. To enable failure access ABR connecting access and metro domains. To enable failure
propagation between those domains, access ABR MUST implement ordered propagation between those domains, access ABR implements ordered
label distribution control when redistributing routes/FEC between the label distribution control when redistributing routes/FEC between the
access-side (using LDP DoD and static or access IGP) and the network- access-side (using LDP DoD and static or access IGP) and the network-
side ( using BGP labeled unicast [RFC3107] or core IGP with LDP side ( using BGP labeled unicast [RFC3107] or core IGP with LDP
Downstream Unsolicited label advertisement. Downstream Unsolicited label advertisement.
4.2. IPv6 Support 4.2. LDP DoD Session Negotiation
Current LDP protocol specification [RFC5036] defines procedures and
messages for exchanging FEC-label bindings over IPv4 and/or IPv6
networks. However number of IPv6 usage areas are not clearly
specified including: packet to LSP mapping for IPv6 destination
router, no IPv6 specific LSP identifier, no LDP discovery using IPv6
multicast address, separate LSPs for IPv4 and IPv6, and others.
All of these issues and more are being addressed by
[I-D.ietf-mpls-ldp-ipv6] that will update LDP protocol specification
[RFC5036] in respect to the IPv6 usage. For the future deployment,
LDP DoD use case and procedures described in this document SHOULD
also support IPv6 for transport and services.
4.3. LDP DoD Session Negotiation
Access LSR/ABR should propose the Downstream-on-Demand label Access LSR/ABR should propose the Downstream-on-Demand label
advertisement by setting "A" value to 1 in the Common Session advertisement by setting "A" value to 1 in the Common Session
Parameters TLV of the Initialization message. The rules for Parameters TLV of the Initialization message. The rules for
negotiating the label advertisement mode are specified in LDP negotiating the label advertisement mode are specified in LDP
protocol specification [RFC5036]. protocol specification [RFC5036].
To establish a Downstream-on-Demand session between the two access To establish a Downstream-on-Demand session between the two access
LSR/ABRs, both should propose the Downstream-on-Demand label LSR/ABRs, both should propose the Downstream-on-Demand label
advertisement mode in the Initialization message. If the access LSR advertisement mode in the Initialization message. If the access LSR
only supports LDP DoD and the access ABR proposes Downstream only supports LDP DoD and the access ABR proposes Downstream
Unsolicited mode, the access LSR SHOULD send a Notification message Unsolicited mode, the access LSR should send a Notification message
with status "Session Rejected/Parameters Advertisement Mode" and then with status "Session Rejected/Parameters Advertisement Mode" and then
close the LDP session as specified in LDP protocol specification close the LDP session as specified in LDP protocol specification
[RFC5036]. [RFC5036].
If an access LSR is acting in an active role, it should re-attempt If an access LSR is acting in an active role, it should re-attempt
the LDP session immediately. If the access LSR receives the same the LDP session immediately. If the access LSR receives the same
Downstream Unsolicited mode again, it should follow the exponential Downstream Unsolicited mode again, it should follow the exponential
backoff algorithm as defined in the LDP protocol specification backoff algorithm as defined in the LDP protocol specification
[RFC5036] with delay of 15 seconds and subsequent delays growing to a [RFC5036] with delay of 15 seconds and subsequent delays growing to a
maximum delay of 2 minutes. maximum delay of 2 minutes.
In case a PWE3 service is required between the adjacent access LSR/ In case a PWE3 service is required between the adjacent access LSR/
ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same
LDP session should be used for PWE3 FECs. Even if LDP DoD label LDP session should be used for PWE3 FECs. Even if LDP DoD label
advertisement has been negotiated for IPv4 and IPv6 LDP FECs as advertisement has been negotiated for IPv4 and IPv6 LDP FECs as
described earlier, LDP session should use Downstream Unsolicited described earlier, LDP session should use Downstream Unsolicited
label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447].
4.4. Label Request Procedures 4.3. Label Request Procedures
4.4.1. Access LSR/ABR Label Request 4.3.1. Access LSR/ABR Label Request
Upstream access LSR/ABR will request label bindings from adjacent Upstream access LSR/ABR will request label bindings from adjacent
downstream access LSR/ABR based on the following trigger events: downstream access LSR/ABR based on the following trigger events:
a. Access LSR/ABR is configured with /32 static route with LDP DoD a. Access LSR/ABR is configured with /32 static route with LDP DoD
label request policy in line with initial network setup use case Label Request policy in line with initial network setup use case
described in Section 3.1. described in Section 3.1.
b. Access LSR/ABR is configured with a service in line with service b. Access LSR/ABR is configured with a service in line with service
use cases described in Section 3.2 and Section 3.3. use cases described in Section 3.2 and Section 3.3.
c. Configuration with access static routes - Access LSR/ABR link to c. Configuration with access static routes - Access LSR/ABR link to
adjacent node comes up and LDP DoD session is established. In adjacent node comes up and LDP DoD session is established. In
this case access LSR should send label request messages for all this case access LSR should send Label Request messages for all /
/32 static routes configured with LDP DoD policy and all /32 32 static routes configured with LDP DoD policy and all /32
routes related to provisioned services that are covered by routes related to provisioned services that are covered by
default route. default route.
d. Configuration with access IGP - Access LSR/ABR link to adjacent d. Configuration with access IGP - Access LSR/ABR link to adjacent
node comes up and LDP DoD session is established. In this case node comes up and LDP DoD session is established. In this case
access LSR should send label request messages for all /32 routes access LSR should send Label Request messages for all /32 routes
learned over the access IGP and all /32 routes related to learned over the access IGP and all /32 routes related to
provisioned services that are covered by access IGP routes. provisioned services that are covered by access IGP routes.
e. In all above cases requests MUST be sent to next-hop LSR(s) and e. In all above cases requests must be sent to next-hop LSR(s) and
alternate LSR(s). alternate LSR(s).
Downstream access LSR/ABR will respond with label mapping message Downstream access LSR/ABR will respond with Label Mapping message
with a non-null label if any of the below conditions are met: with a non-null label if any of the below conditions are met:
a. Downstream access LSR/ABR - requested FEC is an IGP or static a. Downstream access LSR/ABR - requested FEC is an IGP or static
route and there is an LDP label already learnt from the next- route and there is an LDP label already learnt from the next-
next-hop downstream LSR (by LDP DoD or LDP DU). If there is no next-hop downstream LSR (by LDP DoD or LDP DU). If there is no
label for the requested FEC and there is an LDP DoD session to label for the requested FEC and there is an LDP DoD session to
the next-next-hop downstream LSR, downstream LSR MUST send a the next-next-hop downstream LSR, downstream LSR must send a
label request message for the same FEC to the next-next-hop Label Request message for the same FEC to the next-next-hop
downstream LSR. In such case downstream LSR will respond back to downstream LSR. In such case downstream LSR will respond back to
the requesting upstream access LSR only after getting a label the requesting upstream access LSR only after getting a label
from the next-next-hop downstream LSR peer. from the next-next-hop downstream LSR peer.
b. Downstream access ABR only - requested FEC is a BGP labelled b. Downstream access ABR only - requested FEC is a BGP labelled
unicast route [RFC3107] and this BGP route is the best selected unicast route [RFC3107] and this BGP route is the best selected
for this FEC. for this FEC.
Downstream access LSR/ABR may respond with a label mapping with Downstream access LSR/ABR may respond with a Label Mapping with
explicit-null or implicit-null label if it is acting as an egress for explicit-null or implicit-null label if it is acting as an egress for
the requested FEC, or it may respond with "No Route" notification if the requested FEC, or it may respond with "No Route" notification if
no route exists. no route exists.
4.4.2. Label Request Retry 4.3.2. Label Request Retry
If an access LSR/ABR receives a "No route" Notification in response Following LDP specification LDP specification [RFC5036], if an access
to its label request message, it should retry using an exponential LSR/ABR receives a "No route" Notification in response to its Label
backoff algorithm similar to the backoff algoritm mentioned in the Request message, it should retry using an exponential backoff
LDP session negotiation described in Section 4.3. algorithm similar to the backoff algoritm mentioned in the LDP
session negotiation described in Section 4.2.
If there is no response to the sent label request message, the LDP If there is no response to the sent Label Request message, the LDP
specification [RFC5036] (section A.1.1, page# 100) states that the specification [RFC5036] (section A.1.1, page# 100) states that the
LSR should not send another request for the same label to the peer LSR should not send another request for the same label to the peer
and mandates that a duplicate label request is considered a protocol and mandates that a duplicate Label Request is considered a protocol
error and should be dropped by the receiving LSR by sending a error and should be dropped by the receiving LSR by sending a
Notification message. Notification message.
Thus, if there is no response from the downstream peer, the access Thus, if there is no response from the downstream peer, the access
LSR/ABR should not send a duplicate label request message again. LSR/ABR should not send a duplicate Label Request message again.
If the static route corresponding to the FEC gets deleted or if the If the static route corresponding to the FEC gets deleted or if the
DoD request policy is modified to reject the FEC before receiving the DoD request policy is modified to reject the FEC before receiving the
label mapping message, then the access LSR/ABR should send a Label Label Mapping message, then the access LSR/ABR should send a Label
Abort message to the downstream LSR. Abort message to the downstream LSR.
4.4.3. Label Request with Fast-Up Convergence To address the case of slower convergence resulting from described
LDP behavior in line with LDP specification [RFC5036], a new LDP TLV
In some conditions, the exponential backoff algorithm usage described extension is proposed and described in Section 5.
in Section 4.4.2 may result in a longer than desired wait time to get
a successful LDP label to route mapping. An example is when a
specific route is unavailable on the downstream LSR when the label
mapping request from the upstream is received, but later comes back.
In such case using the exponential backoff algorithm may result in a
max delay wait time before the upstream LSR sends another LDP label
request.
Fast-up convergence can be addressed with a minor extension to the
LDP DoD procedure, as described in this section. The downstream and
upstream LSRs SHOULD implement this extension if up convergence
improvement is desired.
The extension consists of the upstream LSR indicating to the
downstream LSR that the label request should be queued on the
downstream LSR until the requested route is available.
To implement this behavior, a new Optional Parameter is defined for
use in the Label Request message:
Optional Parameter Length Value
Queue Request TLV 0 see below
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| Queue Request (0x????) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1
Unknown TLV bit is set to 1. If this optional TLV is unknown,
it should be ignored without sending "no route" notification.
Ensures backward compatibility.
F-bit = 0
Forward unknown TLV bit is set to 0. The unknown TLV is not
forwarded.
Type
Queue Request Type value to be allocated by IANA.
Length = 0x00
Specifies the length of the Value field in octets.
The operation is as follows.
To benefit from the fast-up convergence improvement, the upstream LSR
sends a Label Request message with a Queue Request TLV.
If the downstream LSR supports the Queue Request TLV, it verifies if
route is available and if so it replies with label mapping as per
existing LDP procedures.
If the route is not available, the downstream LSR queues the request
and replies as soon as the route becomes available. In the meantime,
it does not send a "no route" notification back. When sending a
label request with the Queue Request TLV, the upstream LSR does not
retry the Label Request message if it does not receive a reply from
its downstream peer
If the upstream LSR wants to abort an outstanding label request while
the Label Request is queued in the downstream LSR, the upstream LSR
sends a Label Abort Request message, making the downstream LSR to
remove the original request from the queue and send back a
notification Label Request Aborted [RFC5036].
If the downstream LSR does not support the Queue Request TLV, it will
silently ignores it, and sends a "no route" notification back. In
this case the upstream LSR invokes the exponential backoff algorithm
described in Section 4.4.2.
This described procedure ensures backward compatitibility.
4.5. Label Withdraw
4.4. Label Withdraw
If an MPLS label on the downstream access LSR/ABR is no longer valid, If an MPLS label on the downstream access LSR/ABR is no longer valid,
the downstream access LSR/ABR withdraws this FEC/label binding from the downstream access LSR/ABR withdraws this FEC/label binding from
the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] the upstream access LSR/ABR with the Label Withdraw Message [RFC5036]
with a specified label TLV or with an empty label TLV. with a specified label TLV or with an empty label TLV.
Downstream access LSR/ABR SHOULD withdraw a label for specific FEC in Downstream access LSR/ABR should withdraw a label for specific FEC in
the following cases: the following cases:
a. If LDP DoD ingress label is associated with an outgoing label a. If LDP DoD ingress label is associated with an outgoing label
assigned by BGP labelled unicast route, and this route is assigned by BGP labelled unicast route, and this route is
withdrawn. withdrawn.
b. If LDP DoD ingress label is associated with an outgoing label b. If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the IGP route is withdrawn from assigned by LDP (DoD or DU) and the IGP route is withdrawn from
the RIB or downstream LDP session is lost. the RIB or downstream LDP session is lost.
skipping to change at page 26, line 17 skipping to change at page 24, line 40
* there is an LDP session but no label from downstream LSR. See * there is an LDP session but no label from downstream LSR. See
note below. note below.
e. If access LSR/ABR is configured with a policy to reject exporting e. If access LSR/ABR is configured with a policy to reject exporting
label mappings to upstream LSR. label mappings to upstream LSR.
The upstream access LSR/ABR responds to the Label Withdraw Message The upstream access LSR/ABR responds to the Label Withdraw Message
with the Label Release Message [RFC5036]. with the Label Release Message [RFC5036].
After sending label release message to downstream access LSR/ABR, the After sending Label Release message to downstream access LSR/ABR, the
upstream access LSR/ABR should resend label request message, assuming upstream access LSR/ABR should resend Label Request message, assuming
upstream access LSR/ABR still requires the label. upstream access LSR/ABR still requires the label.
Downstream access LSR/ABR should withdraw a label if the local route Downstream access LSR/ABR should withdraw a label if the local route
configuration (e.g. /32 loopback) is deleted. configuration (e.g. /32 loopback) is deleted.
Note: For any events inducing next hop change, downstream access LSR/ Note: For any events inducing next hop change, downstream access LSR/
ABR should attempt to converge the LSP locally before withdrawing the ABR should attempt to converge the LSP locally before withdrawing the
label from an upstream access LSR/ABR. For example if the next-hop label from an upstream access LSR/ABR. For example if the next-hop
changes for a particular FEC and if the new next-hop allocates labels changes for a particular FEC and if the new next-hop allocates labels
by LDP DoD session, then the downstream access LSR/ABR must send a by LDP DoD session, then the downstream access LSR/ABR must send a
label request on the new next-hop session. If downstream access LSR/ Label Request on the new next-hop session. If downstream access LSR/
ABR doesn't get label mapping for some duration, then and only then ABR doesn't get Label Mapping for some duration, then and only then
downstream access LSR/ABR must withdraw the upstream label. downstream access LSR/ABR must withdraw the upstream label.
4.6. Label Release 4.5. Label Release
If an access LSR/ABR does not need any longer a label for a FEC, it If an access LSR/ABR does not need any longer a label for a FEC, it
sends a Label Release Message [RFC5036] to the downstream access LSR/ sends a Label Release Message [RFC5036] to the downstream access LSR/
ABR with or without the label TLV. ABR with or without the label TLV.
If upstream access LSR/ABR receives an unsolicited label mapping on If upstream access LSR/ABR receives an unsolicited Label Mapping on
DoD session, they should release the label by sending label release DoD session, they should release the label by sending Label Release
message. message.
Access LSR/ABR should send a label release message to the downstream Access LSR/ABR should send a Label Release message to the downstream
LSR in the following cases: LSR in the following cases:
a. If it receives a label withdraw from the downstream access LSR/ a. If it receives a Label Withdraw from the downstream access LSR/
ABR. ABR.
b. If the /32 static route with LDP DoD label request policy is b. If the /32 static route with LDP DoD Label Request policy is
deleted. deleted.
c. If the service gets decommissioned and there is no corresponding c. If the service gets decommissioned and there is no corresponding
/32 static route with LDP DoD label request policy configured. /32 static route with LDP DoD Label Request policy configured.
d. If the route next-hop changed, and the label does not point to d. If the route next-hop changed, and the label does not point to
the best or alternate next-hop. the best or alternate next-hop.
e. If it receives a label withdraw from a downstream DoD session. e. If it receives a Label Withdraw from a downstream DoD session.
4.7. Local Repair 4.6. Local Repair
To support local-repair with ECMP and IPFRR LFA, access LSR/ABR MUST To support local-repair with ECMP and IPFRR LFA, access LSR/ABR must
request labels on both the best next-hop and the alternate next-hop request labels on both the best next-hop and the alternate next-hop
LDP DoD sessions, as specified in the label request procedures in LDP DoD sessions, as specified in the Label Request procedures in
Section 4.4. If remote LFA is enabled, access LSR/ABR needs a label Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label
from its alternate next-hop toward the PQ node and needs a label from from its alternate next-hop toward the PQ node and needs a label from
the remote PQ node toward its FEC/destination. If access LSR/ABR the remote PQ node toward its FEC/destination. If access LSR/ABR
doesn't already know those labels, it MUST request them. doesn't already know those labels, it must request them.
This will enable access LSR/ABR to pre-program the alternate This will enable access LSR/ABR to pre-program the alternate
forwarding path with the alternate label(s), and invoke IPFRR LFA forwarding path with the alternate label(s), and invoke IPFRR LFA
switch-over procedure if the primary next-hop link fails. switch-over procedure if the primary next-hop link fails.
5. IANA Considerations 5. LDP Extension for LDP DoD Fast-Up Convergence
In some conditions, the exponential backoff algorithm usage described
in Section 4.3.2 may result in a longer than desired wait time to get
a successful LDP label to route mapping. An example is when a
specific route is unavailable on the downstream LSR when the Label
Mapping request from the upstream is received, but later comes back.
In such case using the exponential backoff algorithm may result in a
max delay wait time before the upstream LSR sends another LDP Label
Request.
5.1. LDP TLV TYPE This section describes an extension to the LDP DoD procedure to
address fast-up convergence, and as such should be treated as a
normative reference. The downstream and upstream LSRs SHOULD
implement this extension if the improvement in up convergence is
desired.
The extension consists of the upstream LSR indicating to the
downstream LSR that the Label Request SHOULD be queued on the
downstream LSR until the requested route is available.
To implement this behavior, a new Optional Parameter is defined for
use in the Label Request message:
Optional Parameter Length Value
Queue Request TLV 0 see below
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| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1
Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit
being set (=1), the unknown TLV MUST be silently ignored and the
rest of the message processed as if the unknown TLV did not exist.
In case requested route is not available, the downstream LSR MUST
ignore this unknown TLV and send a "no route" notification back.
Ensures backward compatibility.
F-bit = 0
Forward unknown TLV bit. This bit applies only when the U-bit is
set and the LDP message containing the unknown TLV is to be
forwarded. Due to F-bit being clear (=0), the unknown TLV is not
forwarded with the containing message.
Type
Queue Request Type value to be allocated by IANA.
Length = 0x00
Specifies the length of the Value field in octets.
Specified operation is as follows.
To benefit from the fast-up convergence improvement, the upstream LSR
sends a Label Request message with a Queue Request TLV.
If the downstream LSR supports the Queue Request TLV, it verifies if
route is available and if so it replies with Label Mapping as per
existing LDP procedures. If the route is not available, the
downstream LSR queues the request and replies as soon as the route
becomes available. In the meantime, it does not send a "no route"
notification back. When sending a Label Request with the Queue
Request TLV, the upstream LSR does not retry the Label Request
message if it does not receive a reply from its downstream peer
If the upstream LSR wants to abort an outstanding Label Request while
the Label Request is queued in the downstream LSR, the upstream LSR
sends a Label Abort Request message, making the downstream LSR to
remove the original request from the queue and send back a
notification Label Request Aborted [RFC5036].
If the downstream LSR does not support the Queue Request TLV, and
requested route is not available, it ignores this unknown TLV and
sends a "no route" notification back in line with [RFC5036]. In this
case the upstream LSR invokes the exponential backoff algorithm
described in Section 4.3.2 following standard LDP specification LDP
specification [RFC5036].
This described procedure ensures backward compatitibility.
6. IANA Considerations
6.1. LDP TLV TYPE
This document uses a new a new Optional Parameter Queue Request TLV This document uses a new a new Optional Parameter Queue Request TLV
in the Label Request message defined in Section 4.4.3. IANA already in the Label Request message defined in Section 5. IANA already
maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by
RFC5036. The following value is suggested for assignment: RFC5036. The following value is suggested for assignment:
TLV type Description TLV type Description
0x0971 Queue Request TLV 0x0971 Queue Request TLV
6. Security Considerations
7. Security Considerations
MPLS LDP Downstream on Demand deployment in the access network is MPLS LDP Downstream on Demand deployment in the access network is
subject to similar security threats as any MPLS LDP deployment. It subject to similar security threats as any MPLS LDP deployment. It
is recommended that baseline security measures are considered as is recommended that baseline security measures are considered as
described in the LDP specification [RFC5036] including ensuring described in Security Framework for MPLS and GMPLS networks [RFC5920]
authenticity and integrity of LDP messages, as well as protection and the LDP specification [RFC5036] including ensuring authenticity
against spoofing and Denial of Service attacks. and integrity of LDP messages, as well as protection against spoofing
and Denial of Service attacks.
Some deployments may require increased measures of network security Some deployments may require increased measures of network security
if a subset of Access Nodes are placed in locations with lower levels if a subset of Access Nodes are placed in locations with lower levels
of physical security e.g. street cabinets (common practice for VDSL of physical security e.g. street cabinets (common practice for VDSL
access). In such cases it is the responsibility of the system access). In such cases it is the responsibility of the system
designer to take into account the physical security measures designer to take into account the physical security measures
(environmental design, mechanical or electronic access control, (environmental design, mechanical or electronic access control,
intrusion detection), as well as monitoring and auditing measures intrusion detection), as well as monitoring and auditing measures
(configuration and Operating System changes, reloads, routes (configuration and Operating System changes, reloads, routes
advertisements). advertisements).
But even with all this in mind, the designer still should consider But even with all this in mind, the designer still should consider
network security risks and adequate measures arising from the lower network security risks and adequate measures arising from the lower
level of physical security of those locations. level of physical security of those locations.
6.1. Security and LDP DoD 7.1. Security and LDP DoD
6.1.1. Access to network packet flow direction 7.1.1. Access to network packet flow direction
An important property of MPLS LDP Downstream on Demand operation is An important property of MPLS LDP Downstream on Demand operation is
that the upstream LSR (requesting LSR) accepts only mappings it sent that the upstream LSR (requesting LSR) accepts only mappings it sent
a request for (in other words the ones it is interested in), and does a request for (in other words the ones it is interested in), and does
not accept any unsolicited label mappings by design. not accept any unsolicited label mappings by design.
This limits the potential of an unauthorized third party fiddling This limits the potential of an unauthorized third party fiddling
with label mappings operations on the wire. It also enables ABR LSR with label mappings operations on the wire. It also enables ABR LSR
to monitor behaviour of any Access LSR in case the latter gets to monitor behaviour of any Access LSR in case the latter gets
compromised and attempts to get access to an unauthorized FEC or compromised and attempts to get access to an unauthorized FEC or
remote LSR. Note that ABR LSR is effectively acting as a gateway to remote LSR. Note that ABR LSR is effectively acting as a gateway to
the MPLS network, and any label mapping requests made by any Access the MPLS network, and any Label Mapping requests made by any Access
LSR are processed and can be monitored on this ABR LSR. LSR are processed and can be monitored on this ABR LSR.
6.1.2. Network to access packet flow direction 7.1.2. Network to access packet flow direction
Another important property of MPLS LDP DoD operation in the access is Another important property of MPLS LDP DoD operation in the access is
that the number of access nodes and associated MPLS FECs per ABR LSR that the number of access nodes and associated MPLS FECs per ABR LSR
is not large in number, and they are all known at the deployment is not large in number, and they are all known at the deployment
time. Hence any changes of the access MPLS FECs can be easily time. Hence any changes of the access MPLS FECs can be easily
controlled and monitored on the ABR LSR. controlled and monitored on the ABR LSR.
And then, even in the event when Access LSR manages to advertise a And then, even in the event when Access LSR manages to advertise a
FEC that belongs to another LSR (e.g. in order to 'steal' third party FEC that belongs to another LSR (e.g. in order to 'steal' third
data flows, or breach a privacy of VPN), such Access LSR will have to party data flows, or breach a privacy of VPN), such Access LSR will
influence the routing decision for affected FEC on the ABR LSR. have to influence the routing decision for affected FEC on the ABR
Following measures SHOULD be considered to prevent such event from LSR. Following measures should be considered to prevent such event
occurring: from occurring:
a. ABR LSR - access side with static routes - this is not possible a. ABR LSR - access side with static routes - this is not possible
for Access LSR. Access LSR has no way to influence ABR LSR for Access LSR. Access LSR has no way to influence ABR LSR
routing decisions due to static nature of routing configuration routing decisions due to static nature of routing configuration
here. here.
b. ABR LSR - access side with IGP - this is still not possible if b. ABR LSR - access side with IGP - this is still not possible if
the compromised Access LSR is a leaf in the access topology (leaf the compromised Access LSR is a leaf in the access topology (leaf
node in topologies I1, I, V, Y described earlier in this node in topologies I1, I, V, Y described earlier in this
document), due to the leaf metrics being configured on the ABR document), due to the leaf metrics being configured on the ABR
LSR. If the compromised Access LSR is a transit LSR in the LSR. If the compromised Access LSR is a transit LSR in the
access topology (transit node in topologies I, Y, U), it is access topology (transit node in topologies I, Y, U), it is
possible for this Access LSR to attract to itself traffic possible for this Access LSR to attract to itself traffic
destined to the nodes upstream from it. However elaborate such destined to the nodes upstream from it. However elaborate such
'man in the middle attack' is possible, but can be quickly 'man in the middle attack' is possible, but can be quickly
detected by upstream Access LSRs not receiving traffic, and detected by upstream Access LSRs not receiving traffic, and
legitimate traffic from them getting dropped. legitimate traffic from them getting dropped.
c. ABR LSR - network side - designer SHOULD consider giving a higher c. ABR LSR - network side - designer should consider giving a higher
administrative preference to the labeled unicast BGP routes vs. administrative preference to the labeled unicast BGP routes vs.
access IGP routes. access IGP routes.
In summary MPLS in access design with LDP DoD has number of native In summary MPLS in access design with LDP DoD has number of native
properties that prevent number of security attacks and make their properties that prevent number of security attacks and make their
detection quick and straightforward. detection quick and straightforward.
Following two sections describe other security considerations Following two sections describe other security considerations
applicable to general MPLS deployments in the access. applicable to general MPLS deployments in the access.
6.2. Data Plane Security 7.2. Data Plane Security
Data plane security risks applicable to the access MPLS network are Data plane security risks applicable to the access MPLS network are
listed below (a non-exhaustive list): listed below (a non-exhaustive list):
a. packets from a specific access node flow to an altered transport a. packets from a specific access node flow to an altered transport
layer or service layer destination. layer or service layer destination.
b. packets belonging to undefined services flow to and from the b. packets belonging to undefined services flow to and from the
access network. access network.
c. unlabelled packets destined to remote network nodes. c. unlabelled packets destined to remote network nodes.
Following mechanisms should be considered to address listed data Following mechanisms should be considered to address listed data
plane security risks: plane security risks:
1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled 1. addressing (a) - Access and ABR LSRs should NOT accept labeled
packets over a particular data link, unless from the Access or packets over a particular data link, unless from the Access or
ABR LSR perspective this data link is known to attach to a ABR LSR perspective this data link is known to attach to a
trusted system based on employed authentication mechanism(s), and trusted system based on employed authentication mechanism(s), and
the top label has been distributed to the upstream neighbour by the top label has been distributed to the upstream neighbour by
the receiving Access or ABR LSR. the receiving Access or ABR LSR.
2. addressing (a) - ABR LSR MAY restrict network reachability for 2. addressing (a) - ABR LSR MAY restrict network reachability for
access devices to a subset of remote network LSR, based on access devices to a subset of remote network LSR, based on
authentication or other network security technologies employed authentication or other network security technologies employed
towards Access LSRs. Restricted reachability can be enforced on towards Access LSRs. Restricted reachability can be enforced on
skipping to change at page 30, line 22 skipping to change at page 30, line 35
unreliable routing peers is achieved by engaging routing protocol unreliable routing peers is achieved by engaging routing protocol
detection and alarm mechanisms, and is out of scope of this detection and alarm mechanisms, and is out of scope of this
document. document.
4. addressing (a) and (b) - no successful attacks have been mounted 4. addressing (a) and (b) - no successful attacks have been mounted
on the control plane and has been detected. on the control plane and has been detected.
5. addressing (c) - ABR LSR MAY restrict IP network reachability to 5. addressing (c) - ABR LSR MAY restrict IP network reachability to
and from the access LSR. and from the access LSR.
6.3. Control Plane Security 7.3. Control Plane Security
Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the data plane Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control
security depends on the security of the control plane. plane security is prerequisite to the data plane security.
To ensure control plane security access LDP DoD connections MUST only To ensure control plane security access LDP DoD sessions should only
be made with LDP peers that are considered trusted from the local LSR be established with LDP peers that are considered trusted from the
perspective, meaning they are reachable over a data link that is local LSR perspective, meaning they are reachable over a data link
known to attach to a trusted system based on employed authentication that is known to attach to a trusted system based on employed
mechanism(s) on the local LSR. authentication mechanism(s) on the local LSR.
The TCP/IP MD5 authentication option [RFC5925] should be used with The security of LDP sesions is analyzed in
LDP as described in LDP specification [RFC5036]. If TCP/IP MD5 [I-D.ietf-karp-routing-tcp-analysis], and its reading is recommended.
authentication is considered not secure enough, the designer may Specifically the TCP/IP MD5 authentication option [RFC5925] should be
used with LDP as described in LDP specification [RFC5036]. If TCP/IP
MD5 authentication is considered not secure enough, the designer may
consider using a more elaborate and advanced TCP Authentication consider using a more elaborate and advanced TCP Authentication
Option (TCP-AO RFC 5925) for LDP session authentication. Option TCP-AO [RFC5925] for LDP session authentication.
Access IGP (if used) and any routing protocols used in access network Access IGP (if used) and any routing protocols used in access network
for signalling service routes SHOULD also be secured in a similar for signaling service routes should also be secured in a similar
manner. manner. Refer to [I-D.ietf-karp-routing-tcp-analysis] and [RFC6863]
for further analysis of security properties of IS-IS and OSPF IGP
routing protocols.
For increased level of authentication in the control plane security For increased level of authentication in the control plane security
for a subset of access locations with lower physical security, for a subset of access locations with lower physical security,
designer could also consider using: designer could also consider using:
o different crypto keys for use in authentication procedures for o different crypto keys for use in authentication procedures for
these locations. these locations.
o stricter network protection mechanisms including DoS protection, o stricter network protection mechanisms including DoS protection,
interface and session flap dampening. interface and session flap dampening.
7. Acknowledgements 7.4. Network Node Security
If a network node, especially an Access Node, is not located in a
physically secured and controlled location, then this Access Node
should implement some measures to provide a level of protection of
the key(s) used to its authenticate to the network, so as to avoid an
attacker to get those keys easily. Software tools should monitor and
keep checking the integrity of the Access Node configuration and
software version. Note that this is not specific to the node using
LDP DoD. In the contrary, the use of LDP DoD will allow the upstream
/network to check, log and possibly deny the FEC requests from the
Access Node.
8. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin
for their suggestions and review. for their suggestions and review.
8. References 9. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
8.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] 9.1. Normative References
Asati, R., Manral, V., Papneja, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07
(work in progress), June 2012.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture", draft-
draft-ietf-mpls-seamless-mpls-02 (work in progress), ietf-mpls-seamless-mpls-02 (work in progress), October
October 2012. 2012.
[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 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
9.2. Informative References
[I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
Authors' Addresses [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013.
Authors' Addresses
Thomas Beckhaus Thomas Beckhaus
Deutsche Telekom AG Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64307 Darmstadt 64307
Germany Germany
Phone: +49 6151 58 12825 Phone: +49 6151 58 12825
Email: thomas.beckhaus@telekom.de Email: thomas.beckhaus@telekom.de
Bruno Decraene Bruno Decraene
 End of changes. 113 change blocks. 
357 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/