draft-ietf-mpls-tp-data-plane-03.txt   draft-ietf-mpls-tp-data-plane-04.txt 
MPLS D. Frost, Ed. MPLS D. Frost, Ed.
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant, Ed.
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 13, 2010 M. Bocci, Ed. Expires: January 2, 2011 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
May 12, 2010 July 1, 2010
MPLS Transport Profile Data Plane Architecture MPLS Transport Profile Data Plane Architecture
draft-ietf-mpls-tp-data-plane-03 draft-ietf-mpls-tp-data-plane-04
Abstract Abstract
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
is the set of MPLS protocol functions applicable to the construction is the set of MPLS protocol functions applicable to the construction
and operation of packet-switched transport networks. This document and operation of packet-switched transport networks. This document
specifies the subset of these functions that comprises the MPLS-TP specifies the subset of these functions that comprises the MPLS-TP
data plane: the architectural layer concerned with the encapsulation data plane: the architectural layer concerned with the encapsulation
and forwarding of packets within an MPLS-TP network. and forwarding of packets within an MPLS-TP network.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 November 13, 2010. This Internet-Draft will expire on January 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 33 skipping to change at page 2, line 33
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. MPLS-TP Packet Encapsulation and Forwarding . . . . . . . . . 4 2. MPLS-TP Packet Encapsulation and Forwarding . . . . . . . . . 4
3. MPLS-TP Transport Entities . . . . . . . . . . . . . . . . . . 5 3. MPLS-TP Transport Entities . . . . . . . . . . . . . . . . . . 5
3.1. Label Switched Paths . . . . . . . . . . . . . . . . . . . 5 3.1. Label Switched Paths . . . . . . . . . . . . . . . . . . . 5
3.1.1. LSP Packet Encapsulation and Forwarding . . . . . . . 5 3.1.1. LSP Packet Encapsulation and Forwarding . . . . . . . 5
3.1.2. LSP Payloads . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. LSP Payloads . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. LSP Types . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. LSP Types . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Sections . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 9
4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 9 4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 10
5. Server Layer Considerations . . . . . . . . . . . . . . . . . 10 5. Server Layer Considerations . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) [I-D.ietf-mpls-tp-framework] is The MPLS Transport Profile (MPLS-TP) is the set of functions that
the set of functions that meet the requirements [RFC5654] for the meet the requirements [RFC5654] for the application of MPLS to the
application of MPLS to the construction and operation of packet- construction and operation of packet-switched transport networks.
switched transport networks. MPLS-based packet transport networks MPLS-based packet-switched transport networks, and the overall
are defined and described in [I-D.ietf-mpls-tp-framework]. architecture of the MPLS-TP, are defined and described in
[I-D.ietf-mpls-tp-framework]. It is assumed that the reader is
familiar with that document.
This document defines the set of functions that comprise the MPLS-TP This document defines the set of functions that comprise the MPLS-TP
data plane: the architectural layer concerned with the encapsulation data plane: the architectural layer concerned with the encapsulation
and forwarding of packets within an MPLS-TP network. This layer is and forwarding of packets within an MPLS-TP network. This layer is
based on the data plane architectures for MPLS ([RFC3031] and based on the data plane architectures for MPLS ([RFC3031] and
[RFC3032]) and for pseudowires ([RFC3985]). [RFC3032]) and for pseudowires ([RFC3985]).
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
skipping to change at page 5, line 4 skipping to change at page 5, line 4
level may be introduced by any pair of LSRs, whereupon they become level may be introduced by any pair of LSRs, whereupon they become
adjacent at this new level, and are then known as Label Edge Routers adjacent at this new level, and are then known as Label Edge Routers
(LERs) with respect to the new LSP. (LERs) with respect to the new LSP.
In contrast to, for example, Section 3.10 of [RFC3031], support for In contrast to, for example, Section 3.10 of [RFC3031], support for
Internet Protocol (IP) host and router data plane functionality by Internet Protocol (IP) host and router data plane functionality by
MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL. MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL.
MPLS-TP forwarding is based on the label that identifies an LSP or MPLS-TP forwarding is based on the label that identifies an LSP or
PW. The label value specifies the processing operation to be PW. The label value specifies the processing operation to be
performed by the next hop at that level of encapsulation. Note that performed by the next hop at that level of encapsulation. A swap of
a swap of this label is an atomic operation in which the contents of this label is an atomic operation in which the contents of the packet
the packet after the swapped label are opaque to the forwarding after the swapped label are opaque to the forwarding function. The
function. The only event that interrupts a swap operation is Time To only event that interrupts a swap operation is Time To Live (TTL)
Live (TTL) expiry. expiry.
At an LSR, S-PE, or T-PE, further processing occurs to determine the At an LSR, S-PE, or T-PE, further processing to determine the context
context of a packet occurs when a swap operation is interrupted by of a packet occurs when a swap operation is interrupted by TTL
TTL expiry. If the TTL of an LSP label expires, then the label with expiry. If the TTL of an LSP label expires, then the label with the
the S (Bottom of Stack) bit set is inspected to determine if it is a S (Bottom of Stack) bit set is inspected to determine if it is a
reserved label. If it is a reserved label, the packet is processed reserved label. If it is a reserved label, the packet is processed
according to the rules of that reserved label. For example, if it is according to the rules of that reserved label. For example, if it is
a Generic Associated Channel Label (GAL), then it is processed as a a Generic Associated Channel Label (GAL), then it is processed as a
packet on the G-ACh; see Section 4. If the TTL of a PW expires at an packet on the G-ACh; see Section 4. If the TTL of a PW expires at an
S-PE or T-PE, then the packet is examined to determine if a Generic S-PE or T-PE, then the packet is examined to determine if a Generic
Associated Channel Header (ACH) is present immediately below the PW Associated Channel Header (ACH) is present immediately below the PW
label. If so, then the packet is processed as a packet on the G-ACh. label. If so, then the packet is processed as a packet on the G-ACh.
Similarly, if a pop operation at an LER exposes a reserved label at Similarly, if a pop operation at an LER exposes a reserved label at
the top of the label stack, then the packet is processed according to the top of the label stack, then the packet is processed according to
skipping to change at page 6, line 13 skipping to change at page 6, line 13
explicitly stated otherwise in this document. explicitly stated otherwise in this document.
Data plane Quality of Service capabilities are included in the Data plane Quality of Service capabilities are included in the
MPLS-TP in the form of Traffic Engineered (TE) LSPs [RFC3209] and the MPLS-TP in the form of Traffic Engineered (TE) LSPs [RFC3209] and the
MPLS Differentiated Services (DiffServ) architecture [RFC3270]. Both MPLS Differentiated Services (DiffServ) architecture [RFC3270]. Both
E-LSP and L-LSP MPLS DiffServ modes are included. The Traffic Class E-LSP and L-LSP MPLS DiffServ modes are included. The Traffic Class
field (formerly the EXP field) of an MPLS label follows the field (formerly the EXP field) of an MPLS label follows the
definition of [RFC5462] and [RFC3270] and MUST be processed according definition of [RFC5462] and [RFC3270] and MUST be processed according
to the rules specified in those documents. to the rules specified in those documents.
Note that, except for transient packet reordering which may occur, Except for transient packet reordering which may occur, for example,
for example, during fault conditions, packets are delivered in order during fault conditions, packets are delivered in order on L-LSPs,
on L-LSPs, and on E-LSPs within a specific ordered aggregate. and on E-LSPs within a specific ordered aggregate.
The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL The Uniform, Pipe and Short Pipe DiffServ tunneling and TTL
processing models described in [RFC3270] and [RFC3443] MAY be used processing models described in [RFC3270] and [RFC3443] MAY be used
for MPLS-TP LSPs. Note however that support for the Pipe or Short for MPLS-TP LSPs. Note however that support for the Pipe or Short
Pipe models is REQUIRED for typical transport applications, in which Pipe models is REQUIRED for typical transport applications, in which
the topology and QoS characteristics of the MPLS-TP server layer are the topology and QoS characteristics of the MPLS-TP server layer are
independent of the client layer. Specific applications MAY place independent of the client layer. Specific applications MAY place
further requirements on the DiffServ tunneling and TTL processing further requirements on the DiffServ tunneling and TTL processing
models an LSP can use. models an LSP can use.
Per-platform, per-interface or other context-specific label space Per-platform, per-interface or other context-specific label space
[RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or [RFC5331] MAY be used for MPLS-TP LSPs. Downstream [RFC3031] or
upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP
LSPs. Note that the requirements of a particular LSP type may LSPs. The requirements of a particular LSP type may, however,
dictate which label spaces or allocation schemes it can use. dictate which label spaces or allocation schemes it can use.
Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on
an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY operate
over a server layer that supports load-balancing, but this load- over a server layer that supports load-balancing, but this load-
balancing MUST operate in such a manner that it is transparent to balancing MUST operate in such a manner that it is transparent to
MPLS-TP. Note that this does not preclude the future definition of MPLS-TP. This does not preclude the future definition of new MPLS-TP
new MPLS-TP LSP types which have different requirements regarding the LSP types which have different requirements regarding the use of ECMP
use of ECMP in the server layer. in the server layer.
Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP
LSPs. LSPs.
3.1.2. LSP Payloads 3.1.2. LSP Payloads
The MPLS-TP includes support for the following LSP payload types: The MPLS-TP includes support for the following LSP payload types:
o Network-layer protocol packets (including MPLS-labeled packets) o Network-layer protocol packets (including MPLS-labeled packets)
o Pseudowire packets o Pseudowire packets
The rules for processing LSP payloads that are network-layer protocol The rules for processing LSP payloads that are network-layer protocol
packets SHALL be as specified in [RFC3032]. packets SHALL be as specified in [RFC3032].
The rules for processing LSP payloads that are pseudowire packets The rules for processing LSP payloads that are pseudowire packets
SHALL be as defined in the data plane pseudowire specifications (see SHALL be as defined in the data plane pseudowire specifications (see
Section 3.3). Section 3.3).
Note that the payload of an MPLS-TP LSP may be a packet that itself The payload of an MPLS-TP LSP may be a packet that itself contains an
contains an MPLS label stack. This is true, for instance, when the MPLS label stack. This is true, for instance, when the payload is a
payload is a pseudowire or an MPLS LSP. In such cases, the label pseudowire or an MPLS LSP. In such cases, the label stack is
stack is contiguous between the MPLS-TP LSP and its payload, and contiguous between the MPLS-TP LSP and its payload, and exactly one
exactly one LSE in this stack SHALL have the S (Bottom of Stack) bit LSE in this stack SHALL have the S (Bottom of Stack) bit set to 1.
set to 1. This behaviour reflects best current practice in MPLS but This behaviour reflects best current practice in MPLS but differs
differs slightly from [RFC3032], which uses the S bit to identify slightly from [RFC3032], which uses the S bit to identify when MPLS
when MPLS label processing stops and network layer processing starts. label processing stops and network layer processing starts.
3.1.3. LSP Types 3.1.3. LSP Types
The MPLS-TP includes the following LSP types: The MPLS-TP includes the following LSP types:
o Point-to-point unidirectional o Point-to-point unidirectional
o Point-to-point associated bidirectional o Point-to-point associated bidirectional
o Point-to-point co-routed bidirectional o Point-to-point co-routed bidirectional
skipping to change at page 8, line 24 skipping to change at page 8, line 24
there is no MPLS layer processing at layer n between the two LSRs there is no MPLS layer processing at layer n between the two LSRs
(other than at the LSRs themselves). Such connectivity, if it (other than at the LSRs themselves). Such connectivity, if it
exists, will be either an MPLS-TP LSP (if n > 0) or a data-link exists, will be either an MPLS-TP LSP (if n > 0) or a data-link
provided by the underlying server layer network (if n = 0), and is provided by the underlying server layer network (if n = 0), and is
referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP
hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are
layer n MPLS-TP sections. Such an LSP is referred to as a client of layer n MPLS-TP sections. Such an LSP is referred to as a client of
the section layer, and the section layer as the server layer with the section layer, and the section layer as the server layer with
respect to its clients. respect to its clients.
Note that the MPLS label stack associated with an MPLS-TP section at The MPLS label stack associated with an MPLS-TP section at layer n
layer n consists of n labels, in the absence of stack optimisation consists of n labels, in the absence of stack optimisation
mechanisms. Note also that in order for two LSRs to exchange non-IP mechanisms. In order for two LSRs to exchange non-IP MPLS-TP control
MPLS-TP control packets over a section, an additional label, the packets over a section, an additional label, the G-ACh Label (GAL)
G-ACh Label (GAL) (see Section 4) MUST appear at the bottom of the (see Section 4) MUST appear at the bottom of the label stack.
label stack.
An MPLS-TP section may provide one or more of the following types of An MPLS-TP section may provide one or more of the following types of
service to its client layer: service to its client layer:
o Point-to-point bidirectional o Point-to-point bidirectional
o Point-to-point unidirectional o Point-to-point unidirectional
o Point-to-multipoint unidirectional o Point-to-multipoint unidirectional
The manner in which a section provides such a service is outside the The manner in which a section provides such a service is outside the
scope of the MPLS-TP. scope of the MPLS-TP.
Note that an LSP of any of the types listed in Section 3.1.3 may An LSP of any of the types listed in Section 3.1.3 may serve as a
serve as a section for a client-layer transport entity as long as it section for a client-layer transport entity as long as it supports
supports the type of service the client requires. the type of service the client requires.
A section MUST provide a means of identifying the type of payload it A section MUST provide a means of identifying the type of payload it
carries. If the section is a data-link, link-specific mechanisms carries. If the section is a data-link, link-specific mechanisms
such as a protocol type indication in the data-link header MAY be such as a protocol type indication in the data-link header MAY be
used. If the section is an LSP, this information MAY be implied by used. If the section is an LSP, this information MAY be implied by
the LSP label or, if the LSP payload is MPLS-labeled, by the setting the LSP label or, if the LSP payload is MPLS-labeled, by the setting
of the S bit. Additional labels MAY also be used if necessary to of the S bit. Additional labels MAY also be used if necessary to
distinguish different payload types; see [I-D.ietf-mpls-tp-framework] distinguish different payload types; see [I-D.ietf-mpls-tp-framework]
for examples and further discussion. for examples and further discussion.
3.3. Pseudowires 3.3. Pseudowires
The data plane architectures for Single-Segment Pseudowires [RFC3985] The data plane architectures for Single-Segment Pseudowires [RFC3985]
and Multi-Segment Pseudowires [RFC5659] are included in the MPLS-TP. and Multi-Segment Pseudowires [RFC5659] are included in the MPLS-TP.
Data plane processing procedures for pseudowires SHALL be as defined Data plane processing procedures for pseudowires are defined and
in the following documents and in any future pseudowire data plane described in a number of IETF documents. Some example pseudowire
specifications: data plane procedures include:
o [RFC4717] o Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN [RFC4385]
o [RFC4816] o Encapsulation Methods for Transport of Ethernet over MPLS Networks
[RFC4448]
o [RFC4385] o Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP) [RFC4553]
o [RFC4448] o Encapsulation Methods for Transport of PPP/High-Level Data Link
Control (HDLC) over MPLS Networks [RFC4618]
o [RFC4619] o Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks [RFC4619]
o [RFC4618] o Encapsulation Methods for Transport of Asynchronous Transfer Mode
(ATM) over MPLS Networks [RFC4717]
o [RFC4553] o Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer
Mode (ATM) Transparent Cell Transport Service [RFC4816]
o [RFC4842] o Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/
SDH) Circuit Emulation over Packet (CEP) [RFC4842]
o [RFC5087] o Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN) [RFC5086]
o [I-D.ietf-pwe3-fc-encap] o Time Division Multiplexing over IP (TDMoIP) [RFC5087]
o [RFC5086] o Encapsulation Methods for Transport of Fibre Channel Frames Over
MPLS Networks [I-D.ietf-pwe3-fc-encap]
This document specifies no modifications or extensions to pseudowire This document specifies no modifications or extensions to pseudowire
data plane architectures or protocols. data plane architectures or protocols.
4. MPLS-TP Generic Associated Channel 4. MPLS-TP Generic Associated Channel
The MPLS Generic Associated Channel (G-ACh) mechanism is specified in The MPLS Generic Associated Channel (G-ACh) mechanism is specified in
[RFC5586] and included in the MPLS-TP. The G-ACh provides an [RFC5586] and included in the MPLS-TP. The G-ACh provides an
auxiliary logical data channel associated with MPLS-TP Sections, auxiliary logical data channel associated with MPLS-TP Sections,
LSPs, and PWs in the data plane. The primary purpose of the G-ACh in LSPs, and PWs in the data plane. The primary purpose of the G-ACh in
skipping to change at page 10, line 17 skipping to change at page 10, line 27
word to provide the initial discrimination between data packets and word to provide the initial discrimination between data packets and
packets belonging to the associated channel, as described in packets belonging to the associated channel, as described in
[RFC4385]. When this first nibble of a packet, immediately following [RFC4385]. When this first nibble of a packet, immediately following
the label at the bottom of stack, has a value of '1', then this the label at the bottom of stack, has a value of '1', then this
packet belongs to a G-ACh. The first 32 bits following the bottom of packet belongs to a G-ACh. The first 32 bits following the bottom of
stack label then have a defined format called an Associated Channel stack label then have a defined format called an Associated Channel
Header (ACH), which further defines the content of the packet. The Header (ACH), which further defines the content of the packet. The
ACH is therefore both a demultiplexer for G-ACh traffic on the PW, ACH is therefore both a demultiplexer for G-ACh traffic on the PW,
and a discriminator for the type of G-ACh traffic. and a discriminator for the type of G-ACh traffic.
When the the control message is carried over a section or an LSP, When the control message is carried over a section or an LSP, rather
rather than over a PW, it is necessary to provide an indication in than over a PW, it is necessary to provide an indication in the
the packet that the payload is something other than a client data packet that the payload is something other than a client data packet.
packet. This is achieved by including a reserved label with a value This is achieved by including a reserved label with a value of 13 at
of 13 at the bottom of the label stack. This reserved label is the bottom of the label stack. This reserved label is referred to as
referred to as the G-ACh Label (GAL), and is defined in [RFC5586]. the G-ACh Label (GAL), and is defined in [RFC5586]. When a GAL is
When a GAL is found, it indicates that the payload begins with an found, it indicates that the payload begins with an ACH. The GAL is
ACH. The GAL is thus a demultiplexer for G-ACh traffic on the thus a demultiplexer for G-ACh traffic on the section or the LSP, and
section or the LSP, and the ACH is a discriminator for the type of the ACH is a discriminator for the type of traffic carried on the
traffic carried on the G-ACh. Note however that MPLS-TP forwarding G-ACh. MPLS-TP forwarding follows the normal MPLS model, and thus a
follows the normal MPLS model, and that a GAL is invisible to an LSR GAL is invisible to an LSR unless it is the top label in the label
unless it is the top label in the label stack. The only other stack. The only other circumstance under which the label stack may
circumstance under which the label stack may be inspected for a GAL be inspected for a GAL is when the TTL has expired. Normal packet
is when the TTL has expired. Note that normal packet forwarding MAY forwarding MAY continue concurrently with this inspection. All
continue concurrently with this inspection. All operations on the operations on the label stack are in accordance with [RFC3031] and
label stack are in accordance with [RFC3031] and [RFC3032]. [RFC3032].
An application processing a packet received over the G-ACh may An application processing a packet received over the G-ACh may
require packet-specific context (such as the receiving interface or require packet-specific context (such as the receiving interface or
received label stack). Data plane implementations MUST therefore received label stack). Data plane implementations MUST therefore
provide adequate context to the application which is to process a provide adequate context to the application which is to process a
G-ACh packet. The definition of the context required MUST be G-ACh packet. The definition of the context required MUST be
provided as part of the specification of the application using the provided as part of the specification of the application using the
G-ACh. G-ACh.
5. Server Layer Considerations 5. Server Layer Considerations
skipping to change at page 11, line 24 skipping to change at page 11, line 34
wish to secure data carried over MPLS-TP transport entities are wish to secure data carried over MPLS-TP transport entities are
REQUIRED to apply their own security mechanisms. REQUIRED to apply their own security mechanisms.
Where management or control plane protocols are used to install label Where management or control plane protocols are used to install label
switching operations necessary to establish MPLS-TP transport paths, switching operations necessary to establish MPLS-TP transport paths,
those protocols are equipped with security features and network those protocols are equipped with security features and network
operators may use those features to securely create the transport operators may use those features to securely create the transport
paths. paths.
Where enhanced security is desirable, and a trust relationship exists Where enhanced security is desirable, and a trust relationship exists
between an LSR and its peer, the LSR MAY choose to discard a packet between an LSR and its peer, the LSR MAY choose to implement the
received from a particular neighbour unless one of the following two following policy for the processing of MPLS packets received from one
conditions holds: or more of its neighbours:
1. Any MPLS label processed at the receiving LSR, such as an LSP or Upon receipt of an MPLS packet, discard the packet unless one of
PW label, has a label value that the receiving LSR has the following two conditions holds:
distributed to that neighbour; or
2. Any MPLS label processed at the receiving LSR, such as an LSP or 1. Any MPLS label in the packet's label stack processed at the
PW label, has a label value that the receiving LSR has previously receiving LSR, such as an LSP or PW label, has a label value
distributed to the peer beyond that neighbour (i.e., when it is that the receiving LSR has distributed to that neighbour; or
known that the path from the system to which the label was
distributed to the receiving system is via that neighbour). 2. Any MPLS label in the packet's label stack processed at the
receiving LSR, such as an LSP or PW label, has a label value
that the receiving LSR has previously distributed to the peer
beyond that neighbour (i.e., when it is known that the path
from the system to which the label was distributed to the
receiving system is via that neighbour).
Further details of MPLS and MPLS-TP security can be found in Further details of MPLS and MPLS-TP security can be found in
[I-D.ietf-mpls-tp-framework] and [I-D.ietf-mpls-tp-framework] and
[I-D.ietf-mpls-mpls-and-gmpls-security-framework]. [I-D.ietf-mpls-mpls-and-gmpls-security-framework].
7. IANA Considerations 7. IANA Considerations
This document introduces no new IANA considerations. This document introduces no new IANA considerations.
8. References 8. References
skipping to change at page 14, line 8 skipping to change at page 14, line 20
draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work
in progress), March 2010. in progress), March 2010.
[I-D.ietf-mpls-tp-framework] [I-D.ietf-mpls-tp-framework]
Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-12 (work in progress), draft-ietf-mpls-tp-framework-12 (work in progress),
May 2010. May 2010.
[I-D.ietf-pwe3-fc-encap] [I-D.ietf-pwe3-fc-encap]
Black, D., Roth, M., Tsurusawa, M., Solomon, R., and L. Black, D. and L. Dunbar, "Encapsulation Methods for
Dunbar, "Encapsulation Methods for Transport of Fibre Transport of Fibre Channel frames Over MPLS Networks",
Channel frames Over MPLS Networks", draft-ietf-pwe3-fc-encap-11 (work in progress), June 2010.
draft-ietf-pwe3-fc-encap-10 (work in progress),
February 2010.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P.
Pate, "Structure-Aware Time Division Multiplexed (TDM) Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, December 2007. (CESoPSN)", RFC 5086, December 2007.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
 End of changes. 33 change blocks. 
92 lines changed or deleted 105 lines changed or added

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