draft-ietf-mpls-tp-data-plane-02.txt   draft-ietf-mpls-tp-data-plane-03.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: October 24, 2010 M. Bocci, Ed. Expires: November 13, 2010 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
April 22, 2010 May 12, 2010
MPLS Transport Profile Data Plane Architecture MPLS Transport Profile Data Plane Architecture
draft-ietf-mpls-tp-data-plane-02 draft-ietf-mpls-tp-data-plane-03
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 October 24, 2010. This Internet-Draft will expire on November 13, 2010.
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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 9
4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 9 4. MPLS-TP Generic Associated Channel . . . . . . . . . . . . . . 9
5. Server Layer Considerations . . . . . . . . . . . . . . . . . 10 5. Server Layer Considerations . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
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) [I-D.ietf-mpls-tp-framework] is
the set of functions that meet the requirements [RFC5654] for the the set of functions that meet the requirements [RFC5654] for the
application of MPLS to the construction and operation of packet- application of MPLS to the construction and operation of packet-
switched transport networks. MPLS-based packet transport networks switched transport networks. MPLS-based packet transport networks
are defined and described in [I-D.ietf-mpls-tp-framework]. are defined and described in [I-D.ietf-mpls-tp-framework].
skipping to change at page 4, line 13 skipping to change at page 4, line 13
are outside the scope of this document. are outside the scope of this document.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
------- ------------------------------------------ ------- ------------------------------------------
ACH Associated Channel Header ACH Associated Channel Header
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label GAL G-ACh Label
LER Label Edge Router LER Label Edge Router
LSE Label Stack Entry
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
OAM Operations, Administration and Maintenance OAM Operations, Administration and Maintenance
PW Pseudowire PW Pseudowire
QoS Quality of Service QoS Quality of Service
S-PE PW Switching Provider Edge Node S-PE PW Switching Provider Edge Node
T-PE PW Terminating Provider Edge Node T-PE PW Terminating Provider Edge Node
TTL Time To Live TTL Time To Live
skipping to change at page 6, line 17 skipping to change at page 6, line 17
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, Note that, except for transient packet reordering which may occur,
for example, during fault conditions, packets are delivered in order for example, during fault conditions, packets are delivered in order
on L-LSPs, and on E-LSPs within a specific ordered aggregate. on L-LSPs, and on E-LSPs within a specific ordered aggregate.
Support for the 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] is REQUIRED by processing models described in [RFC3270] and [RFC3443] MAY be used
the MPLS-TP. Support for the Uniform model is OPTIONAL. for MPLS-TP LSPs. Note however that support for the Pipe or Short
Pipe models is REQUIRED for typical transport applications, in which
the topology and QoS characteristics of the MPLS-TP server layer are
independent of the client layer. Specific applications MAY place
further requirements on the DiffServ tunneling and TTL processing
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. Note that the requirements of a particular LSP type may
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-
skipping to change at page 7, line 7 skipping to change at page 7, line 11
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 Note that the payload of an MPLS-TP LSP may be a packet that itself
contains an MPLS label stack. This is true, for instance, when the contains an MPLS label stack. This is true, for instance, when the
payload is a pseudowire or an MPLS LSP. In this case the S (Bottom payload is a pseudowire or an MPLS LSP. In such cases, the label
of Stack) bit SHALL be set to indicate the bottom (i.e. inner-most) stack is contiguous between the MPLS-TP LSP and its payload, and
label in the label stack that is contiguous between the MPLS-TP LSP exactly one LSE in this stack SHALL have the S (Bottom of Stack) bit
and its payload. This behaviour reflects best current practice in set to 1. This behaviour reflects best current practice in MPLS but
MPLS but differs slightly from [RFC3032], which uses the S bit to differs slightly from [RFC3032], which uses the S bit to identify
identify when MPLS label processing stops and network layer when MPLS label processing stops and network layer processing starts.
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 10 skipping to change at page 8, line 13
transmits on the LSP is transmitted out all associated egress transmits on the LSP is transmitted out all associated egress
interfaces. Point-to-multipoint LSPs are described in [RFC4875] and interfaces. Point-to-multipoint LSPs are described in [RFC4875] and
[RFC5332]. TTL processing and exception handling for point-to- [RFC5332]. TTL processing and exception handling for point-to-
multipoint LSPs is the same as for point-to-point LSPs and is multipoint LSPs is the same as for point-to-point LSPs and is
described in Section 2. described in Section 2.
3.2. Sections 3.2. Sections
Two MPLS-TP LSRs are considered to be topologically adjacent at a Two MPLS-TP LSRs are considered to be topologically adjacent at a
particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists
connectivity between them at the next lowest network layer. Such connectivity between them at the next lowest network layer, and if
connectivity, if it exists, will be either an MPLS-TP LSP (if n > 0) there is no MPLS layer processing at layer n between the two LSRs
or a data-link provided by the underlying server layer network (if n (other than at the LSRs themselves). Such connectivity, if it
= 0), and is referred to as an MPLS-TP Section at layer n of the exists, will be either an MPLS-TP LSP (if n > 0) or a data-link
MPLS-TP LSP hierarchy. Thus, the links traversed by a layer n+1 provided by the underlying server layer network (if n = 0), and is
MPLS-TP LSP are layer n MPLS-TP sections. Such an LSP is referred to referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP
as a client of the section layer, and the section layer as the server hierarchy. Thus, the links traversed by a layer n+1 MPLS-TP LSP are
layer with respect to its clients. 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
respect to its clients.
Note that the MPLS label stack associated with an MPLS-TP section at Note that the MPLS label stack associated with an MPLS-TP section at
layer n consists of n labels, in the absence of stack optimisation layer n consists of n labels, in the absence of stack optimisation
mechanisms. Note also that in order for two LSRs to exchange non-IP mechanisms. Note also that in order for two LSRs to exchange non-IP
MPLS-TP control packets over a section, an additional label, the MPLS-TP control packets over a section, an additional label, the
G-ACh Label (GAL) (see Section 4) MUST appear at the bottom of the G-ACh Label (GAL) (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:
skipping to change at page 8, line 42 skipping to change at page 8, line 47
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 Note that an LSP of any of the types listed in Section 3.1.3 may
serve as a section for a client-layer transport entity as long as it serve as a section for a client-layer transport entity as long as it
supports the type of service the client requires. supports the type of service the client requires.
An important difference exists between data-link-based sections and A section MUST provide a means of identifying the type of payload it
LSP-based sections. A data-link-based section can carry additional carries. If the section is a data-link, link-specific mechanisms
packet context information such as a protocol type indication. If an such as a protocol type indication in the data-link header MAY be
LSP-based section requires such context, then a service label (see used. If the section is an LSP, this information MAY be implied by
[I-D.ietf-mpls-tp-framework]) must be used to provide it. 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
distinguish different payload types; see [I-D.ietf-mpls-tp-framework]
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 SHALL be as defined
in the following documents and in any future pseudowire data plane in the following documents and in any future pseudowire data plane
specifications: specifications:
skipping to change at page 11, line 8 skipping to change at page 11, line 13
underlying links operating as a bundle. Special care may be needed underlying links operating as a bundle. Special care may be needed
in network design and operation when such constructs are used as a in network design and operation when such constructs are used as a
server layer for MPLS-TP. server layer for MPLS-TP.
Encapsulation of MPLS-TP packets for transport over specific server- Encapsulation of MPLS-TP packets for transport over specific server-
layer media is outside the scope of this document. layer media is outside the scope of this document.
6. Security Considerations 6. Security Considerations
The MPLS data plane (and therefore the MPLS-TP data plane) does not The MPLS data plane (and therefore the MPLS-TP data plane) does not
provide any security mechanisms in and of itself. The following provide any security mechanisms in and of itself. Client layers that
behaviour, however, is considered a best current practise for MPLS wish to secure data carried over MPLS-TP transport entities are
LSRs which is also applicable to MPLS-TP: REQUIRED to apply their own security mechanisms.
An LSR SHOULD discard a packet received from a particular neighbour Where management or control plane protocols are used to install label
unless one of the following two conditions holds: switching operations necessary to establish MPLS-TP transport paths,
those protocols are equipped with security features and network
operators may use those features to securely create the transport
paths.
Where enhanced security is desirable, and a trust relationship exists
between an LSR and its peer, the LSR MAY choose to discard a packet
received from a particular neighbour unless one of the following two
conditions holds:
1. Any MPLS label processed at the receiving LSR, such as an LSP or 1. Any MPLS label processed at the receiving LSR, such as an LSP or
PW label, has a label value that the receiving LSR has PW label, has a label value that the receiving LSR has
distributed to that neighbour; or distributed to that neighbour; or
2. Any MPLS label processed at the receiving LSR, such as an LSP or 2. Any MPLS label processed at the receiving LSR, such as an LSP or
PW label, has a label value that the receiving LSR has previously PW label, has a label value that the receiving LSR has previously
distributed to the peer beyond that neighbour (i.e., when it is distributed to the peer beyond that neighbour (i.e., when it is
known that the path from the system to which the label was known that the path from the system to which the label was
distributed to the receiving system is via that neighbour). distributed to the receiving system is via that neighbour).
Client layers that wish to secure data carried over MPLS-TP transport Further details of MPLS and MPLS-TP security can be found in
entities are REQUIRED to apply their own security mechanisms. [I-D.ietf-mpls-tp-framework] and
Where management or control plane protocols are used to install label
switching operations necessary to establish MPLS-TP transport paths,
those protocols are equipped with security features and network
operators may use those features to securely create the transport
paths.
Further details of MPLS security can be found in
[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
8.1. Normative References 8.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.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
skipping to change at page 13, line 44 skipping to change at page 14, line 4
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] [I-D.ietf-mpls-mpls-and-gmpls-security-framework]
Fang, L. and M. Behringer, "Security Framework for MPLS Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks", and GMPLS Networks",
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-11 (work in progress), draft-ietf-mpls-tp-framework-12 (work in progress),
April 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., Roth, M., Tsurusawa, M., Solomon, R., and L.
Dunbar, "Encapsulation Methods for Transport of Fibre Dunbar, "Encapsulation Methods for Transport of Fibre
Channel frames Over MPLS Networks", Channel frames Over MPLS Networks",
draft-ietf-pwe3-fc-encap-10 (work in progress), draft-ietf-pwe3-fc-encap-10 (work in progress),
February 2010. 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.
 End of changes. 16 change blocks. 
48 lines changed or deleted 57 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/