draft-chen-mpls-source-label-05.txt   draft-chen-mpls-source-label-06.txt 
Network Working Group M. Chen Network Working Group M. Chen
Internet-Draft X. Xu Internet-Draft X. Xu
Intended status: Standards Track Z. Li Intended status: Standards Track Z. Li
Expires: January 4, 2015 Huawei Expires: April 16, 2015 Huawei
L. Fang L. Fang
Microsoft Microsoft
G. Mirsky G. Mirsky
Ericsson Ericsson
July 3, 2014 October 13, 2014
MultiProtocol Label Switching (MPLS) Source Label MultiProtocol Label Switching (MPLS) Source Label
draft-chen-mpls-source-label-05 draft-chen-mpls-source-label-06
Abstract Abstract
A MultiProtocol Label Switching (MPLS) label was originally defined A MultiProtocol Label Switching (MPLS) label was originally defined
to identify a Forwarding Equivalence Class (FEC), a packet is to identify a Forwarding Equivalence Class (FEC). A packet is
assigned to a specific FEC based on its network layer destination assigned to a specific FEC based on its network layer destination
address. It's difficult or even impossible to derive the source address, and optionally Class of Service. It's difficult or even
identity information from the label. For some applications, source impossible to derive the source identity information from the label.
identification is a critical requirement. For example, performance For some applications, source identification is a critical
monitoring, where the monitoring node needs to identify where a requirement. For example, performance monitoring, where the
packet was sent from. monitoring node needs to identify where a packet was sent from.
This document introduces the concept of Source Label (SL) that is This document introduces the concept of Source Identifier (SI) that
carried in the label stack and used to identify the ingress Label identifies the ingress Label Switching Router (LSR) of a Label
Switching Router (LSR) of an Label Switched Path (LSP). Switched Path (LSP). A SI is unique within a domain that is referred
to as Source Identifier Administrative Domain (SIAD).
This document also introduces the concept of Source Label (SL) that
is carried in the label stack and carries the SI of the ingress LSR
of an LSP. Source Label is preceded by a Source Label Indicator
(SLI) when included the label stack and is not used for forwarding.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [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
skipping to change at page 2, line 7 skipping to change at page 2, line 12
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 January 4, 2015. This Internet-Draft will expire on April 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 34
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. Problem Statement and Introduction . . . . . . . . . . . . . 3 1. Problem Statement and Introduction . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Source Label . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Source Label . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Performance Measurement Use Case . . . . . . . . . . . . . . 5
4.1. Performance Measurement . . . . . . . . . . . . . . . . . 5 5. Data Plane Processing . . . . . . . . . . . . . . . . . . . . 5
5. Data Plane Processing . . . . . . . . . . . . . . . . . . . . 6 5.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 6 5.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 6
6. Source Label Signaling . . . . . . . . . . . . . . . . . . . 7 6. Source Label Capability Signaling . . . . . . . . . . . . . . 6
6.1. Source Label Capability Signaling . . . . . . . . . . . . 7 6.1. LDP Extensions . . . . . . . . . . . . . . . . . . . . . 6
6.1.1. LDP Extensions . . . . . . . . . . . . . . . . . . . 7 6.2. BGP Extensions . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. BGP Extensions . . . . . . . . . . . . . . . . . . . 8 6.2.1. Sending/Receiving Restriction . . . . . . . . . . . . 8
6.1.3. IGP Extensions . . . . . . . . . . . . . . . . . . . 9 6.3. IGP Extensions . . . . . . . . . . . . . . . . . . . . . 9
6.2. Source Label Distribution . . . . . . . . . . . . . . . . 9 7. Source Identifier Distribution . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Source Label Indication . . . . . . . . . . . . . . . . . 10 8.1. Source Label Indication . . . . . . . . . . . . . . . . . 9
7.2. LDP Source Label Capability TLV . . . . . . . . . . . . . 10 8.2. LDP Source Label Capability TLV . . . . . . . . . . . . . 10
7.3. BGP Source Label Capability Attribute . . . . . . . . . . 10 8.3. BGP Source Label Capability Attribute . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Problem Statement and Introduction 1. Problem Statement and Introduction
A MultiProtocol Label Switching (MPLS) label [RFC3031] was originally A MultiProtocol Label Switching (MPLS) label [RFC3031] was originally
defined for packet forwarding and assumes the forwarding/destination defined for packet forwarding and assumes the forwarding/destination
address semantics. As no source identity information is carried in address semantics. As no source identity information is carried in
the label stack, there is no way to directly derive the source the label stack, in many cases there is no way to directly derive the
identity information from the label or label stack. source identity information from the label or label stack.
MPLS LSPs can be categorized into four different types: MPLS LSPs can be categorized into four different types:
Point-to-Point (P2P) o Point-to-Point (P2P)
Point-to-Multipoint (P2MP) o Point-to-Multipoint (P2MP)
Multipoint-to-Point (MP2P) o Multipoint-to-Point (MP2P)
Multipoint-to-Multipoint (MP2MP) o Multipoint-to-Multipoint (MP2MP)
For P2P and P2MP LSPs (e.g., the Resource Reservation Protocol For P2P and P2MP LSPs (e.g., the Resource Reservation Protocol
Traffic Engineering (RSVP-TE) [RFC3209] based and statically Traffic Engineering (RSVP-TE) [RFC3209] based and statically
configured P2P and P2MP LSPs), the source identity may be implicitly configured P2P and P2MP LSPs), the source identity may be implicitly
derived by the egress LSR from the label when Penultimate Hop Popping derived by the egress LSR from the label when Penultimate Hop Popping
(PHP) is disabled and the correlation between ingress LSR and the LSP (PHP) is disabled and the correlation between ingress LSR and the LSP
is explicitly signaled through the control plane. Such LSP may be is explicitly signaled through the control plane. Such LSP may be
characterized as MPLS-TP LSP [RFC5960]. characterized as MPLS-TP LSP [RFC5960].
However, for MP2P and MP2MP LSPs (e.g., the Distribution Protocol However, for MP2P and MP2MP LSPs (e.g., the Label Distribution
(LDP) based LSPs [RFC5036] [RFC6388], and Layer 3 Private Network Protocol (LDP) based LSPs [RFC5036] [RFC6388], and Layer 3 Private
(L3VPN) [RFC4364] LSPs), ingress LSRs of those LSPs cannot be Network (L3VPN) [RFC4364] LSPs), ingress LSRs of those LSPs cannot be
identified by egress LSRs. identified by egress LSRs.
Comparing to the pure IP forwarding where both source and destination Comparing to the pure IP forwarding where both source and destination
addresses are encoded in the IP packet header, the essential issue of addresses are encoded in the IP packet header, the essential issue of
the MPLS encoding is that the label stack does not explicitly include the MPLS encoding is that the label stack does not explicitly include
any source identity information. For some applications, source any source identity information. For some applications, source
identification is a critical requirement. For example, performance identification is a critical requirement. For example, performance
monitoring, the monitoring nodes need to identify where packets were monitoring, the monitoring nodes need to identify where packets were
sent from and then can count the packets according to some sent from and then can count the packets according to some
constraints. constraints.
This document introduces the concept of Source Label (SL). An SL This document introduces the concept of Source Label (SL). An SL is
uniquely identifies a node within an administrative domain, it is carried in the label stack and carries the identifier of the ingress
carried in the label stack and used to identify the ingress LSR that LSR that originated the MPLS frame.
originated the MPLS frame.
2. Terminology 2. Terminology
SI - Source Identifier
SIAD - Source Identifier Administrative Domain
SL - Source Label SL - Source Label
SLC - Source Label Capability SLC - Source Label Capability
SLI - Source Label Indicator SLI - Source Label Indicator
SLAD - Source Label Administrative Domain
3. Source Label 3. Source Label
A Source Label is defined to uniquely identify a node that is (one A Source Label is defined to carry an identifier (Source Identifier)
of) the ingress LSR(s) to a specific LSP. In its function as a of a node that is (one of) the ingress LSR(s) to specific LSP.
Source Label, it MUST be unique within a domain. In cases where a Source Label SHOULD NOT be used for forwarding and is not signaled.
Source Label is used across domains it MUST be unique within the
scope it is used. In this document, the domain or domains that the
Source Label is required to be unique is referred as a "Source Label
Administrative Domain" (SLAD).
To prevent the Source Label from leaking to unintended domains, two
aspects need to be considered:
In control plane, it SHOULD make sure that the Source Label will
not be distributed outside the SLAD where it is used. And since
the ingress LSR is based on the Source Label Capability signaled
by the egress LSR to determine whether to insert the Source Label,
the SLC signaling SHOULD make sure that the SLC will not be
signaled to the LSRs that reside in other SLADs.
In data plane, the domain boundary nodes (e.g., the ASBR) SHOULD
have the capability to filter out the packets that carry the SL/
SLI and are received from other SLADs. For example, some policies
(e.g., by ACL) could be deployed at the ASBR to filter out the
packets that carry SLI and are from other SLADs.
The Source Labels are allocated from a dedicated label space that is
completely different from the space of the normal forwarding labels.
Configuration system (e.g., static configuration or NMS) is one way
to make sure the uniqueness of each SL assigned to specific LSR.
There may be some other potential dynamic solutions that can be used
for SL allocation and distribution. This is left for future study.
For most of the cases, one Source Label per LSR is enough. But for A Source Identifier (SI) is a number in the range of [16, 65535].
some cases, there may need more than one Source Labels. For example, Each node in a domain MUST be allocated one or more unique SIs, the
in the L3VPN scenario, it may require to allocate dedicated Source domain is referred as a "Source Identifier Administrative Domain"
Label to identify each VPN instance. This requires that the Source (SIAD). For most of the use cases, one SI per LSR would be
Label distribution protocol MUST have the capability to process this sufficient. But for some cases, there may be need for more than one
"one or more Source Labels per LSR" situation. SIs. For example, in the L3VPN scenario, it may be necessary to
allocate a dedicated SI to identify each VPN instance.
In order to indicate whether a label is a Source Label, a Source In order to indicate whether a label is a Source Label, a Source
Label Indicator (SLI) is introduced. The SLI is a special purpose Label Indicator (SLI) is introduced. The SLI is a special purpose
label [RFC7274] that is placed immediately before the source label in label [RFC7274] that is placed immediately before the source label in
the label stack, which is used to indicate that the next label in the the label stack, which is used to indicate that the next label in the
label stack is the Source Label. Throughout the document mention to label stack is the Source Label. The value of SLI is TBD1. The SL
a Source Label refers to the combination of SLI and SL. The value of is an example of context label [RFC5331], the SLI is the context.
SLI is TBD1.
4. Use Cases To prevent the Source Label from leaking to unintended domains, two
aspects need to be considered:
This section outlines the use cases which benefit from application of o In the control plane, the Source Label MUST NOT be distributed
Source Label. outside the SIAD where it is used. Since the ingress LSR is based
on the Source Label Capability signaled by the egress LSR to
determine whether to insert the Source Label, the SLC signaling
MUST make sure that the SLC will not be signaled to the LSRs that
reside in other SIADs.
4.1. Performance Measurement o In the data plane, the domain boundary nodes (e.g., the ASBR)
SHOULD have the capability to filter out the packets that carry
the SL/SLI and are received from other SIADs. For example, some
policies (e.g., using ACL) could be deployed at the ASBR to filter
out the packets that carry SL/SLI and are from other SIADs.
4. Performance Measurement Use Case
There are two general types of performance measurement: one is active There are two general types of performance measurement: one is active
performance measurement, and the other is passive performance performance measurement, and the other is passive performance
measurement. measurement.
In active performance measurement the receiver measures the injected In active performance measurement the receiver measures the injected
packets to evaluate the performance of a path. The active packets to evaluate the performance of a path. The active
measurement measures the performance of the extra injected packets. measurement measures the performance of the extra injected packets.
The IP Performance Metrics (IPPM) working group has defined The IP Performance Metrics (IPPM) working group has defined
specifications [RFC4656][RFC5357] for the active performance specifications [RFC4656][RFC5357] for active performance measurement.
measurement.
In passive performance measurement, no additional traffic is injected In passive performance measurement, no additional traffic is injected
into the flow and measurements are taken to record the performance into the flow and measurements are taken to record the performance
metrics of the data traffic. The MPLS performance measurement metrics of the data traffic. The MPLS performance measurement
protocol [RFC6374] for packet loss is an example of passive protocol [RFC6374] for packet loss is an example of passive
performance measurement, but it can only apply to MPLS-TE LSPs. For performance measurement, but currently it can only be measured for
a specific receiver, in order to count the received packets of a MPLS-TE LSPs. For a specific receiver, in order to count the
flow, it has to know whether a received packet belongs to which received packets of a flow, the system doing the measurement (e.g.,
target flow under test and the source identification is a critical egress router) needs to know which target flow a received packet
condition. belongs to. Source identification is therefore necessary. Source
identification may be achieved by including appropriate MEP-ID
[RFC6428].
As discussed in the previous section, the existing MPLS label or As discussed in the previous section, the existing MPLS label or
label stack do not carry the source information. So, for an LSP, the label stack does not carry the source information. So, for an LSP,
ingress LSR can put its Source Label in the label stack, and then the the ingress LSR can put its SI in the Source Label, and then the
egress LSR can use the Source Label for packets identification of egress LSR can use the SI to identify the packet's source, in order
frame's source and accounting. to facilitate accounting.
5. Data Plane Processing 5. Data Plane Processing
5.1. Ingress LSR 5.1. Ingress LSR
For an LSP, the ingress LSR MUST make sure that the egress LSR is For an LSP, the ingress LSR MUST make sure that the egress LSR is
able to process the Source Label before inserting the SLI/SL able to process the Source Label before inserting the SLI/SL
combination into the label stack. Therefore, an egress LSR SHOULD combination into the label stack. Therefore, an egress LSR SHOULD
signal (see Section 6.1) to the ingress LSR whether it is able to signal (see Section 6) to the ingress LSR whether it is able to
process the Source Label. Once the ingress LSR knows that the egress process the Source Label. Once the ingress LSR knows that the egress
LSR can process Source Label, it can choose whether or not to insert LSR can process Source Label, it can choose whether or not to insert
the SL and SLI into the label stack. the SL and SLI into the label stack.
When an SL to be included in a label stack, the steps are as follows: When an SL to be included in a label stack, the steps are as follows:
1. Push the SL, the TTL of the SL MUST be set to 1, the BoS bit for 1. Push the SL, the TTL of the SL MUST be set to 1, the BoS bit for
the SL depends on whether the SL is the bottom label. Setting the SL depends on whether the SL is the bottom label. Setting
and interpretation of TC field of the SL is for further study; and interpretation of TC field of the SL is for further study;
2. Push the SLI, the TTL and TC fields for the SLI MUST be set to 2. Push the SLI, the TTL and TC fields for the SLI MUST be set to
the same values as for the LSP Label (L); the same values as for the LSP Label (L);
3. Push the LSP Label (L). 3. Push the LSP Label (L).
Then the label stack looks like: <...L, SLI, SL [,...]>. There MAY Then the label stack looks like: <...L, SLI, SL [,...]>. There MAY
be multiple pairs of SLI and SL inserted into the label stack, each be multiple combinations of SLI and SL inserted into the label stack,
pair is related to an LSP. For the given LSP, only one pair of SLI each combination is related to an LSP. For the given LSP, only one
and SL MUST be inserted. combination of SLI and SL MUST be inserted.
5.2. Transit LSR 5.2. Transit LSR
There is no change in forwarding behavior for transit LSRs. If a There is no change in forwarding behavior for transit LSRs. If a
transit LSR can recognize the SLI, it can use the SL to collect transit LSR can recognize the SLI, it can use the SL to collect
traffic throughput and/or measure the performance of the LSP. traffic throughput and/or measure the performance of the LSP.
5.3. Egress LSR 5.3. Egress LSR
When an egress LSR receives a packet with a SLI/SL combination, if When an egress LSR receives a packet with a SLI/SL combination, if
skipping to change at page 7, line 5 skipping to change at page 6, line 35
any), SLI and SL; then processes remaining packet header as normal. any), SLI and SL; then processes remaining packet header as normal.
If the egress LSR is not able to process the SLI, the packet SHOULD If the egress LSR is not able to process the SLI, the packet SHOULD
be dropped as specified for the handling of any unknown label be dropped as specified for the handling of any unknown label
according to [RFC3031]. according to [RFC3031].
5.4. Penultimate Hop LSR 5.4. Penultimate Hop LSR
There is no change in forwarding behavior for the penultimate hop There is no change in forwarding behavior for the penultimate hop
LSR. LSR.
6. Source Label Signaling 6. Source Label Capability Signaling
Source label signaling includes two aspects: one is source label
capability signaling, the other is source label distribution.
6.1. Source Label Capability Signaling
Before inserting a Source Label in the label stack, an ingress LSR Before inserting a Source Label in the label stack, an ingress LSR
SHOULD know whether the egress LSR is able to process the Source SHOULD know whether the egress LSR is able to process the SLI and SL.
Label. Therefore, an egress LSR SHOULD signal to the ingress LSRs Therefore, an egress LSR SHOULD signal to the ingress LSRs its
its ability to process the Source Label. This is called Source Label ability to process the SLI and SL. This is called Source Label
Capability (SLC), it is very similar to the "Entropy Label Capability Capability (SLC), it is very similar to the "Entropy Label Capability
(ELC)"[RFC6790]. (ELC)"[RFC6790].
6.1.1. LDP Extensions 6.1. LDP Extensions
A new LDP TLV [RFC5036], SLC TLV, is defined to signal an egress's A new LDP TLV [RFC5036], SLC TLV, is defined to signal an egress's
ability to process Source Label. The SLC TLV MAY appear as an ability to process Source Label. The SLC TLV MAY appear as an
Optional Parameter of the Label Mapping Message. The presence of the Optional Parameter of the Label Mapping Message. The presence of the
SLC TLV in a Label Mapping Message indicates to ingress LSRs that the SLC TLV in a Label Mapping Message indicates to ingress LSRs that the
egress LSR can process Source Labels for the associated LSP. egress LSR can process Source Labels for the associated LSP.
The structure of the SLC TLV is shown below. The structure of the SLC TLV is shown below.
0 1 2 3 0 1 2 3
skipping to change at page 8, line 23 skipping to change at page 7, line 48
Withdraw for a previously advertised Mapping for F, X MUST re- Withdraw for a previously advertised Mapping for F, X MUST re-
evaluate the status of SLC for FEC F, and, if there is a change, X evaluate the status of SLC for FEC F, and, if there is a change, X
MUST re-advertise its Mapping for F with the updated status of SLC. MUST re-advertise its Mapping for F with the updated status of SLC.
LDP is normally running within an AS, technically, it can be deployed LDP is normally running within an AS, technically, it can be deployed
across ASes. An implementation supports the SLC MUST support a per- across ASes. An implementation supports the SLC MUST support a per-
session/per-interface configuration item to enable/disable the SLC. session/per-interface configuration item to enable/disable the SLC.
For the session/interface that connects to other SLADs, the SLC MUST For the session/interface that connects to other SLADs, the SLC MUST
be disabled. be disabled.
6.1.2. BGP Extensions 6.2. BGP Extensions
When Border Gateway Protocol (BGP) [RFC4271] is used for distributing When Border Gateway Protocol (BGP) [RFC4271] is used for distributing
Network Layer Reachability Information (NLRI) as described in, for Network Layer Reachability Information (NLRI) as described in, for
example, [RFC3107], [RFC4364], the BGP UPDATE message may include the example, [RFC3107], [RFC4364], the BGP UPDATE message may include the
SLC attribute as part of the Path Attributes. This is an optional, SLC attribute as part of the Path Attributes. This is an optional,
non-transitive BGP attribute of value TBD3. The inclusion of this non-transitive BGP attribute of value TBD3. The inclusion of this
attribute with an NLRI indicates that the advertising BGP router can attribute with an NLRI indicates that the advertising BGP router can
process Source Labels as an egress LSR for all routes in that NLRI. process Source Labels as an egress LSR for all routes in that NLRI.
A BGP speaker S that originates an UPDATE should include the SLC A BGP speaker S that originates an UPDATE should include the SLC
skipping to change at page 9, line 12 skipping to change at page 8, line 35
An example of the use of B1 is Route Reflectors. However, if T An example of the use of B1 is Route Reflectors. However, if T
changes the NEXT_HOP attribute for U and in the data plane pops the changes the NEXT_HOP attribute for U and in the data plane pops the
entire label stack to process the payload, T MAY include an SLC entire label stack to process the payload, T MAY include an SLC
attribute for UPDATE U' if both of the following are true: attribute for UPDATE U' if both of the following are true:
C1: T sets the NEXT_HOP attribute of U' to itself AND C1: T sets the NEXT_HOP attribute of U' to itself AND
C2: T can process source labels. Otherwise, T MUST remove the SLC C2: T can process source labels. Otherwise, T MUST remove the SLC
attribute. attribute.
6.1.2.1. Sending/Receiving Restriction 6.2.1. Sending/Receiving Restriction
An implementation that supports the SLC MUST support per-session An implementation that supports the SLC MUST support per-session
configuration item, SL_SESSION, that indicates whether the SLC is configuration item, SL_SESSION, that indicates whether the SLC is
enabled or disabled for use on that session. enabled or disabled for use on that session.
- The default value of SL_SESSION, for EBGP sessions, MUST be - The default value of SL_SESSION, for EBGP sessions, MUST be
"disabled". "disabled".
- The default value of SL_SESSION, for IBGP and confederation-EBGP - The default value of SL_SESSION, for IBGP and confederation-EBGP
[RFC5065]sessions, SHOULD be "enabled." [RFC5065]sessions, SHOULD be "enabled."
The SLC attribute MUST NOT be sent on any BGP session for which The SLC attribute MUST NOT be sent on any BGP session for which
SL_SESSION is disabled. SL_SESSION is disabled.
If an SLC attribute is received on a BGP session for which SL_SESSION If an SLC attribute is received on a BGP session for which SL_SESSION
is disabled, the attribute MUST be treated exactly as if it were an is disabled, the attribute MUST be treated exactly as if it were an
unrecognized non-transitive attribute. That is, "it MUST be quietly unrecognized non-transitive attribute. That is, "it MUST be quietly
ignored and not passed along to other BGP peers" (see [RFC4271], ignored and not passed along to other BGP peers" (see [RFC4271],
section 5). section 5).
6.1.3. IGP Extensions 6.3. IGP Extensions
No dedicated SLC signaling defined in this document, as defined in IGP based SLC applies to the scenarios where IGP is used for label
[I-D.chen-isis-source-label-distribution] and mapping (e.g., Segment Routing). IGP SLC signaling is defined in
[I-D.chen-ospf-source-label-distribution], the presence of a Source [I-D.chen-isis-source-identifier-distribution] and
Label TLV MUST be interpreted as support of SLC by the LSR. That [I-D.chen-ospf-source-identifier-distribution], the presence of a
means the SLC is implicitly indicated by receiving a SL distribution Source Identifier TLV/sub-TLV MUST be interpreted as support of SLC
from an LSR. by the LSR. That means the SLC is implicitly indicated by receiving
a SI distribution from an LSR.
6.2. Source Label Distribution 7. Source Identifier Distribution
Based on the Source Label, an egress or intermediate LSR can identify Based on the Source Identifier, an egress or intermediate LSR can
from where an MPLS packet is sent. To achieve this, the egress and/ identify from where an MPLS packet is sent. To achieve this, the
or intermediate LSRs have to know which ingress LSR is related to egress and/or intermediate LSRs have to know which ingress LSR is
which Source Label before using the Source Label to derive the source related to which Source Identifier before using the Source Identifier
information. Therefore, there needs to be a mechanism to distribute to derive the source information. Therefore, there needs to be a
the mapping information between an ingress LSR and its Source Label. mechanism to distribute the mapping information between an ingress
LSR and its SI(s).
IGP based Source Label distributions are defined in IGP based SI distribution documents,
[I-D.chen-isis-source-label-distribution] [I-D.chen-isis-source-identifier-distribution],
[I-D.chen-ospf-source-label-distribution], which apply to the intra- [I-D.chen-ospf-source-identifier-distribution], define extensions to
AS scenario. corresponding IGP protocols necessary for intra-AS scenario.
For inter-AS scenario, BGP extension is a naturally choice and can be For inter-AS scenario, BGP extension is a naturally choice and can be
used to convey SL mapping information from one AS to other ASes. The used to convey SI mapping information from one AS to other ASes. The
BGP extension draft is work in progress. For BGP based SL BGP extension draft is work in progress. For BGP based SI
distribution, it requires that SLs MUST not be sent out of a SLAD. distribution, it requires that SIs MUST not be sent out of a SIAD.
The similar sending and receiving restriction as defined in The similar sending and receiving restriction as defined in
Section 6.1.3 is also needed. Section 6.2.1 is also needed.
7. IANA Considerations 8. IANA Considerations
7.1. Source Label Indication 8.1. Source Label Indication
IANA is required to allocate a special purpose label (TBD1) for the IANA is required to allocate a special purpose label (TBD1) for the
Source Label Indicator (SLI) from the "Multiprotocol Label Switching Source Label Indicator (SLI) from the "Multiprotocol Label Switching
Architecture (MPLS) Label Values" Registry. Architecture (MPLS) Label Values" Registry.
7.2. LDP Source Label Capability TLV 8.2. LDP Source Label Capability TLV
IANA is requested to allocate a value of TBD2 from the IETF Consensus IANA is requested to allocate a value of TBD2 from the IETF Consensus
range (0x0001-0x07FF) in the "TLV Type Name Space" registry as the range (0x0001-0x07FF) in the "TLV Type Name Space" registry as the
"Source Label Capability TLV". "Source Label Capability TLV".
7.3. BGP Source Label Capability Attribute 8.3. BGP Source Label Capability Attribute
IANA is requested to allocate a Path Attribute Type Code TBD3 from IANA is requested to allocate a Path Attribute Type Code TBD3 from
the "BGP Path Attributes" registry as the "BGP Source Label the "BGP Path Attributes" registry as the "BGP Source Label
Capability Attribute". Capability Attribute".
8. Security Considerations 9. Security Considerations
This document introduces the SLAD that is the scope of a SL, SLC and This document introduces the SIAD that is the scope of a SL. The SLC
SL MUST NOT be signaled and distributed outside one SLAD. The SLC and SI MUST NOT be signaled and distributed outside one SIAD. BGP
and SL distribution is controlled by SL_SESSION configuration, based SLC and SI distribution is controlled by SL_SESSION
improper configuration on both ends of an EBGP connection could configuration. Improper configuration on both ends of an EBGP
result in the SLC and SL being passed from one SLAD to another. This connection could result in the SLC and SI being passed from one SIAD
would likely result in potential SL conflicts. to another. This would likely result in potential SI conflicts.
To prevent packets carrying SL/SLI from leaking from one SLAD to To prevent packets carrying SL/SLI from leaking from one SIAD to
another, the SLAD boundary nodes SHOULD deploy some policies (e.g., another, the SIAD boundary nodes SHOULD deploy some policies (e.g.,
ACL) to filter out the packets. Specifically, in the sending end, ACL) to filter out the packets. Specifically, in the sending end,
the SLAD boundary node SHOULD filter out the packets that carry the the SIAD boundary node SHOULD filter out the packets that carry the
SLI and are sent to other SLADs; in the receiving end, the SLAD SLI and are sent to other SIADs; in the receiving end, the SIAD
boundary node SHOULD drop the packets that carry the SLI and are from boundary node SHOULD drop the packets that carry the SLI and are from
other SLADs. other SIADs.
9. Acknowledgements 10. Acknowledgements
The process of "Source Label Capability Signaling" is largely The process of "Source Label Capability Signaling" is largely
referred to the process of "ELC signaling"[RFC6790]. referred to the process of "ELC signaling"[RFC6790].
The authors would like to thank Carlos Pignataro, Loa Andersson , The authors would like to thank Carlos Pignataro, Loa Andersson ,
Curtis Villamizar, Eric Osborne, Eric Rosen, Yimin Shen, Lizhong Jin Curtis Villamizar, Eric Osborne, Eric Rosen, Yimin Shen, Lizhong Jin,
and Yakov Rekhter for their review, suggestion and comments to this Ross Callon and Yakov Rekhter for their review, suggestion and
document. comments to this document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
skipping to change at page 11, line 47 skipping to change at page 11, line 27
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274, June and Retiring Special-Purpose MPLS Labels", RFC 7274, June
2014. 2014.
10.2. Informative References 11.2. Informative References
[I-D.chen-isis-source-label-distribution] [I-D.chen-isis-source-identifier-distribution]
Chen, M. and G. Mirsky, "Extensions to ISIS for Source Chen, M. and G. Mirsky, "Extensions to ISIS for Source
Label Distribution", draft-chen-isis-source-label- Identifier Distribution", draft-chen-isis-source-
distribution-00 (work in progress), February 2014. identifier-distribution-00 (work in progress), October
2014.
[I-D.chen-ospf-source-label-distribution] [I-D.chen-ospf-source-identifier-distribution]
Chen, M. and G. Mirsky, "Extensions to OSPF for Source Chen, M. and G. Mirsky, "Extensions to OSPF for Source
Label Distribution", draft-chen-ospf-source-label- Identifier Distribution", draft-chen-ospf-source-
distribution-00 (work in progress), February 2014. identifier-distribution-00 (work in progress), October
2014.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
skipping to change at page 12, line 31 skipping to change at page 12, line 16
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007. 4761, January 2007.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. System Confederations for BGP", RFC 5065, August 2007.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010. Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
Authors' Addresses Authors' Addresses
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
 End of changes. 61 change blocks. 
168 lines changed or deleted 167 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/