One document matched: draft-ietf-mpls-tp-requirements-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-tp-requirements-09"
ipr="trust200811">
<front>
<title abbrev="MPLS-TP Requirements">MPLS-TP Requirements</title>
<author fullname="Ben Niven-Jenkins" initials="B.P." role="editor"
surname="Niven-Jenkins">
<organization>BT</organization>
<address>
<postal>
<street>208 Callisto House, Adastral Park</street>
<city>Ipswich</city>
<region>Suffolk</region>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<email>benjamin.niven-jenkins@bt.com</email>
</address>
</author>
<author fullname="Deborah Brungard" initials="D." role="editor"
surname="Brungard">
<organization>AT&T</organization>
<address>
<postal>
<street>Rm. D1-3C22 - 200 S. Laurel Ave.</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>dbrungard@att.com</email>
</address>
</author>
<author fullname="Malcolm Betts" initials="M." role="editor"
surname="Betts">
<organization>Nortel Networks</organization>
<address>
<postal>
<street>3500 Carling Avenue</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K2H 8E9</code>
<country>Canada</country>
</postal>
<email>betts01@nortel.com</email>
</address>
</author>
<author fullname="Nurit Sprecher" initials="N." role="" surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region></region>
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Satoshi Ueno" initials="S." role="" surname="Ueno">
<organization>NTT</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>satoshi.ueno@ntt.com</email>
</address>
</author>
<date year="2009" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International
Telecommunications Union (ITU)-IETF effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by International Telecommunications Union - Telecommunications
Standardization Sector (ITU-T).</t>
<t>This work is based on two sources of requirements; MPLS and PWE3
architectures as defined by IETF, and packet transport networks as
defined by ITU-T.</t>
<t>The requirements expressed in this document are for the behavior of
the protocol mechanisms and procedures that constitute building blocks
out of which the MPLS transport profile is constructed. The requirements
are not implementation requirements.</t>
</abstract>
<note title="Requirements Language">
<t>Although this document is not a protocol specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref> and are to be
interpreted as instructions to the protocol designers producing
solutions that satisfy the requirements set out in this document.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and
multimedia applications:<list style="symbols">
<t>Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling, etc.,</t>
<t>Applications with various bandwidth and Quality of Service (QoS)
requirements.</t>
</list></t>
<t>This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements.</t>
<t>Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Network (OTN)) has provided
carriers with a high benchmark for reliability and operational
simplicity.</t>
<t>With the movement towards packet based services, the transport
network has to evolve to encompass the provision of packet aware
capabilities while enabling carriers to leverage their installed, as
well as planned, transport infrastructure investments.</t>
<t>Carriers are in need of technologies capable of efficiently
supporting packet based services and applications on their transport
networks with guaranteed Service Level Agreements (SLAs). The need to
increase their revenue while remaining competitive forces operators to
look for the lowest network Total Cost of Ownership (TCO). Investment in
equipment and facilities (Capital Expenditure (CAPEX)) and Operational
Expenditure (OPEX) should be minimized.</t>
<t>There are a number of technology options for carriers to meet the
challenge of increased service sophistication and transport efficiency,
with increasing usage of hybrid packet transport and circuit transport
technology solutions. To realize these goals, it is essential that
packet transport technology be available that can support the same high
benchmarks for reliability and operational simplicity set by SDH/SONET
and OTN technologies.</t>
<t>Furthermore for carriers it is important that operation of such
packet transport networks should preserve the look-and-feel to which
carriers have become accustomed in deploying their optical transport
networks, while providing common, multi-layer operations, resiliency,
control and multi-technology management.</t>
<t>Transport carriers require control and deterministic usage of network
resources. They need end-to-end control to engineer network paths and to
efficiently utilize network resources. They require capabilities to
support static (management plane based) or dynamic (control plane based)
provisioning of deterministic, protected and secured services and their
associated resources.</t>
<t>It is also important to ensure smooth interworking of the packet
transport network with other existing/legacy packet networks, and
provide mappings to enable packet transport carriage over a variety of
transport network infrastructures. The latter has been termed vertical
interworking, and is also known as client/server or network
interworking. The former has been termed horizontal interworking, and is
also known as peer-partition or service interworking. For more details
on interworking and some of the issues that may arise (especially with
horizontal interworking) see <xref target="ITU.G805.2000"> G.805</xref>
and <xref target="ITU.Y1401.2008">Y.1401</xref>.</t>
<t>Multi-Protocol Label Switching (MPLS) is a maturing packet technology
and it is already playing an important role in transport networks and
services. However, not all of MPLS's capabilities and mechanisms are
needed and/or consistent with transport network operations. There are
also transport technology characteristics that are not currently
reflected in MPLS. There is therefore the need to define an MPLS
Transport Profile (MPLS-TP) that supports the capabilities and
functionalities needed for packet transport network services and
operations through combining the packet experience of MPLS with the
operational experience and practices of existing transport networks.</t>
<t>MPLS-TP will enable the depoyment of packet based transport networks
that will efficiently scale to support packet services in a simple and
cost effective way. MPLS-TP needs to combine the necessary existing
capabilities of MPLS with additional minimal mechanisms in order that it
can be used in a transport role.</t>
<t>This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). The requirements are for the behavior of the protocol
mechanisms and procedures that constitute building blocks out of which
the MPLS transport profile is constructed. That is, the requirements
indicate what features are to be available in the MPLS toolkit for use
by MPLS-TP. The requirements in this document do not describe what
functions an MPLS-TP implementation supports. The purpose of this
document is to identify the toolkit and any new protocol work that is
required.</t>
<t>Although this document is not a protocol specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as described in
<xref target="RFC2119"></xref> and are to be interpreted as instructions
to the protocol designers producing solutions that satisfy the
requirements set out in this document.</t>
<t>This document is a product of a joint ITU-T and IETF effort to
include an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a
packet transport network as defined by ITU-T.</t>
<t>This work is based on two sources of requirements, MPLS and PWE3
architectures as defined by IETF and packet transport networks as
defined by ITU-T. The requirements of MPLS-TP are provided below. The
relevant functions of MPLS and PWE3 are included in MPLS-TP, except
where explicitly excluded.</t>
<t>Although both static and dynamic configuration of MPLS-TP transport
paths (including Operations, Administration and Maintenance (OAM) and
protection capabilities) is required by this document, it MUST be
possible for operators to be able to completely operate (including OAM
and protection capabilities) an MPLS-TP network in the absence of any
control plane.</t>
<section title="Terminology">
<t>Note: Mapping between the terms in this section and ITU-T
terminology is described in <xref
target="I-D.helvoort-mpls-tp-rosetta-stone"></xref>.</t>
<t>The recovery requirements in this document use the recovery
terminology defined in RFC 4427 <xref target="RFC4427"></xref>, this
is applied to both control plane and management plane based operations
of MPLS-TP transport paths.</t>
<section title="Abbreviations">
<t>ASON: Automatically Switched Optical Network</t>
<t>ATM: Asynchronous Transfer Mode</t>
<t>CAPEX: Capital Expenditure</t>
<t>CE: Customer Edge</t>
<t>FR: Frame Relay</t>
<t>GMPLS: Generalised Multi-Protocol Label Switching</t>
<t>IGP: Interior Gateway Protocol</t>
<t>IPTV: IP Television</t>
<t>L2: Layer 2</t>
<t>L3: Layer 3</t>
<t>LSP: Label Switched Path</t>
<t>LSR: Label Switching Router</t>
<t>MPLS: Multi-Protocol Label Switching</t>
<t>OAM: Operations, Administration and Maintenance</t>
<t>OPEX: Operational Expenditure</t>
<t>OSI: Open Systems Interconnection</t>
<t>OTN: Optical Transport Network</t>
<t>P2MP: Point to Multi-Point</t>
<t>P2P: Point to Point</t>
<t>PDU: Protocol Data Unit</t>
<t>PSC: Protection State Coordination</t>
<t>PW: Pseudo Wire</t>
<t>QoS: Quality of Service</t>
<t>SDH: Synchronous Digital Hierarchy</t>
<t>SLA: Service Level Agreement</t>
<t>SLS: Service Level Specification</t>
<t>S-PE: Switching Provider Edge</t>
<t>SONET: Synchronous Optical Network</t>
<t>SRLG: Shared Risk Link Group</t>
<t>TCO: Total Cost of Ownership</t>
<t>T-PE: Terminating Provider Edge</t>
<t>VoIP: Voice over IP</t>
<t>VPN: Virtual Private Network</t>
<t>WDM: Wavelength Division Multiplexing</t>
</section>
<section title="Definitions">
<t>Note: The definition of segment in a GMPLS/ASON context (i.e. as
defined in <xref target="RFC4397">RFC4397</xref>) encompasses both
segment and concatenated segment as defined in this document.</t>
<t>Associated bidirectional path: A path that supports traffic flow
in both directions but which is constructed from a pair of
unidirectional paths (one for each direction) which are associated
with one another at the path's ingress/egress points. The forward
and backward directions are setup, monitored and protected
independently. As a consequence they may or may not follow the same
route (links and nodes) across the network.</t>
<t>Client layer network: In a client/server relationship (see <xref
target="ITU.G805.2000">G.805</xref>), the client layer network
receives a (transport) service from the lower server layer network
(usually the layer network under consideration).</t>
<t>Concatenated Segment: A serial-compound link connection as
defined in <xref target="ITU.G805.2000">G.805</xref>. A concatenated
segment is a contiguous part of an LSP or multi-segment PW that
comprises a set of segments and their interconnecting nodes in
sequence. See also "Segment".</t>
<t>Control Plane: Within the scope of this document the control
plane performs transport path control functions. Through signalling,
the control plane sets up, modifies and releases transport paths,
and may recover a transport path in case of a failure. The control
plane also performs other functions in support of transport path
control, such as routing information dissemination.</t>
<t>Co-routed Bidirectional path: A path where the forward and
backward directions follow the same route (links and nodes) across
the network. Both directions are setup, monitored and protected as a
single entity. A transport network path is typically co-routed.</t>
<t>Domain: A domain represents a collection of entities (for example
network elements) that are grouped for a particular purpose,
examples of which are administrative and/or managerial
responsibilities, trust relationships, addressing schemes,
infrastructure capabilities, aggregation, survivability techniques,
distributions of control functionality, etc. Examples of such
domains include IGP areas and Autonomous Systems.</t>
<t>Layer network: Layer network is defined in <xref
target="ITU.G805.2000">G.805</xref>. A layer network provides for
the transfer of client information and independent operation of the
client OAM. A Layer Network may be described in a service context as
follows: one layer network may provide a (transport) service to
higher client layer network and may, in turn, be a client to a lower
layer network. A layer network is a logical construction somewhat
independent of arrangement or composition of physical network
elements. A particular physical network element may topologically
belong to more than one layer network, depending on the actions it
takes on the encapsulation associated with the logical layers (e.g.
the label stack), and thus could be modeled as multiple logical
elements. A layer network may consist of one or more sublayers.
<xref target="LayerNetworkOverview"></xref> provides a more detailed
overview of what constitutes a layer network. For additional
explanation of how layer networks relate to the OSI concept of
layering see Appendix I of <xref
target="ITU.Y2611.2006">Y.2611</xref>.</t>
<t>Link: A physical or logical connection between a pair of LSRs
that are adjacent at the (sub)layer network under consideration. A
link may carry zero, one or more LSPs or PWs. A packet entering a
link will emerge with the same label stack entry values.</t>
<t>MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from
a set of LSRs and logical data links (such as MPLS-TP LSP tunnels or
MPLS-TP pseudowires) and physical data links that form a ring
topology.</t>
<t>Path: See Transport Path.</t>
<t>MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed
from a set of LSRs and physical data links that form a ring
topology.</t>
<t>MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is
connected to exactly two other LSRs, each via a single
point-to-point bidirectional MPLS-TP capable link. A ring may also
be constructed from only two LSRs where there are also exactly two
links. Rings may be connected to other LSRs to form a larger
network. Traffic originating or terminating outside the ring may be
carried over the ring. Client network nodes (such as CEs) may be
connected directly to an LSR in the ring.</t>
<t>Section Layer Network: A section layer is a server layer (which
may be MPLS-TP or a different technology) which provides for the
transfer of the section layer client information between adjacent
nodes in the transport path layer or transport service layer. A
section layer may provide for aggregation of multiple MPLS-TP
clients. Note that <xref target="ITU.G805.2000">G.805</xref> defines
the section layer as one of the two layer networks in a transmission
media layer network. The other layer network is the physical media
layer network.</t>
<t>Segment: A link connection as defined in <xref
target="ITU.G805.2000">G.805</xref>. A segment is the part of an LSP
that traverses a single link or the part of a PW that traverses a
single link (i.e. that connects a pair of adjacent
{Switching|Terminating} Provider Edges). See also "Concatenated
Segment".</t>
<t>Server Layer Network: In a client/server relationship (see <xref
target="ITU.G805.2000">G.805</xref>), the server layer network
provides a (transport) service to the higher client layer network
(usually the layer network under consideration).</t>
<t>Sublayer: Sublayer is defined in <xref
target="ITU.G805.2000">G.805</xref>. The distinction between a layer
network and a sublayer is that a sublayer is not directly accessible
to clients outside of its encapsulating layer network and offers no
direct transport service for a higher layer (client) network.</t>
<t>Switching Provider Edge (S-PE): See <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref>.</t>
<t>Terminating Provider Edge (T-PE): See <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref>.</t>
<t>Transport Path: A network connection as defined in <xref
target="ITU.G805.2000">G.805</xref>. In an MPLS-TP environment a
transport path corresponds to an LSP or a PW.</t>
<t>Transport Path Layer: A (sub-)layer network that provides
point-to-point or point-to-multipoint transport paths. It provides
independent (of the client) OAM when transporting its clients.</t>
<t>Transport Service Layer: A layer network in which transport paths
are used to carry a customer’s (individual or bundled) service
(may be point-to-point, point-to-multipoint or
multipoint-to-multipoint services).</t>
<t>Transmission Media Layer: A layer network, consisting of a
section layer network and a physical layer network as defined in
<xref target="ITU.G805.2000">G.805</xref>, that provides sections
(two-port point-to-point connections) to carry the aggregate of
network transport path or network service layers on various physical
media.</t>
<t>Unidirectional Path: A path that supports traffic flow in only
one direction.</t>
</section>
</section>
<section title="Transport network overview">
<t>The connectivity service is the basic service provided by a
transport network. The purpose of a transport network is to carry its
customer traffic (i.e. the stream of customer PDUs or customer bits,
including overhead) between endpoints in the transport network
(typically over several intermediate nodes). The connectivity services
offered to customers are typically aggregated into large transport
paths with long-holding times and independent OAM (of the client OAM),
which contribute to enabling the efficient and reliable operation of
the transport network. These transport paths are modified
infrequently.</t>
<t>Quality-of-service mechanisms are required in the packet transport
network to ensure the prioritization of critical services, to
guarantee bandwidth and to control jitter and delay. A transport
network must provide the means to commit quality of service objectives
to clients. This is achieved by providing a mechanism for client
network service demarcation for the network path together with an
associated network resiliency mechanism.</t>
<t>Aggregation is beneficial for achieving scalability and security
since: <list style="numbers">
<t>It reduces the number of provisioning and forwarding states in
the network core.</t>
<t>It reduces load and the cost of implementing service assurance
and fault management.</t>
<t>Customer traffic is encapsulated and layer associated OAM
overhead is added. This allows complete isolation of customer
traffic and its management from carrier operations.</t>
</list></t>
<t>An important attribute of a transport network is that it is able to
function regardless of which clients are using its connection service
or over which transmission media it is running. The client, transport
network and server layers are from a functional and operations point
of view independent layer networks. Another key characteristic of
transport networks is the capability to maintain the integrity of the
client across the transport network. A transport network must also
provide a method of service monitoring in order to verify the delivery
of an agreed quality of service. This is enabled by means of
carrier-grade OAM tools.</t>
<t>Customer traffic is first encapsulated within the transport service
layer network. The transport service layer network signals may then be
aggregated into a transport path layer network for transport through
the network in order to optimize network management. Transport service
layer network OAM is used to monitor the transport integrity of the
customer traffic and transport path layer network OAM is used to
monitor the transport integrity of the aggregates. At any hop, the
aggregated signals may be further aggregated in lower layer transport
network paths for transport across intermediate shared links. The
transport service layer network signals are extracted at the edges of
aggregation domains, and are either delivered to the customer or
forwarded to another domain. In the core of the network, only the
transport path layer network signals are monitored at intermediate
points; individual transport service layer network signals are
monitored at the network boundary. Although the connectivity of the
transport service layer network may be point-to-point,
point-to-multipoint or multipoint-to-multipoint, the transport path
layer network only provides point-to-point or point-to-multipoint
transport paths which are used to carry aggregates of transport
service layer network traffic.</t>
</section>
<section anchor="LayerNetworkOverview" title="Layer network overview">
<t>A layer network provides its clients with a transport service and
the operation of the layer network is independent of whatever client
happens to use the layer network. Information that passes between any
client to the layer network is common to all clients and is the
minimum needed to be consistent with the definition of the transport
service offered. The client layer network can be connectionless,
connection oriented packet switched, or circuit switched. The
transport service transfers a payload (individual packet payload for
connectionless networks, a sequence of packets payloads in the case of
connection oriented packet switched networks, and a deterministic
schedule of payloads in the case of circuit switched networks) such
that the client can populate the payload without affecting any
operation within the serving layer network.</t>
<t>The operations within a layer network that are independent of its
clients include the control of forwarding, the control of resource
reservation, the control of traffic demerging, and the OAM and
recovery of the transport service. All of these operations are
internal to a layer network. By definition, a layer network does not
rely on any client information to perform these operations and
therefore all information required to perform these operations is
independent of whatever client is using the layer network.</t>
<t>A layer network will have consistent features in order to support
the control of forwarding, resource reservation, OAM and recovery. For
example, a layer network will have a common addressing scheme for the
end points of the transport service and a common set of transport
descriptors for the transport service. However, a client may use a
different addressing scheme or different traffic descriptors
(consistent with performance inheritance).</t>
<t>It is sometimes useful to independently monitor a smaller domain
within a layer network (or the transport services that traverse this
smaller domain) but the control of forwarding or the control of
resource reservation involved retain their common elements. These
smaller monitored domains are sublayers.</t>
<t>It is sometimes useful to independently control forwarding in a
smaller domain within a layer network but the control of resource
reservation and OAM retain their common elements. These smaller
domains are partitions of the layer network.</t>
</section>
</section>
<section title="MPLS-TP Requirements">
<t>This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). The requirements are for the behavior of the protocol
mechanisms and procedures that constitute building blocks out of which
the MPLS transport profile is constructed. That is, the requirements
indicate what features are to be available in the MPLS toolkit for use
by MPLS-TP. The requirements in this document do not describe what
functions an MPLS-TP implementation supports. The purpose of this
document is to identify the toolkit and any new protocol work that is
required.</t>
<section title="General requirements">
<t><list counter="Requirements" style="format %d">
<t>The MPLS-TP data plane MUST be a subset of the MPLS data plane
as defined by the IETF. When MPLS offers multiple options in this
respect, MPLS-TP SHOULD select the minimum sub-set (necessary and
sufficient subset) applicable to a transport network
application.</t>
<t>Any new functionality that is defined to fulfill the
requirements for MPLS-TP MUST be agreed within the IETF through
the IETF consensus process as per <xref
target="RFC4929"></xref></t>
<t>The MPLS-TP design SHOULD as far as reasonably possible re-use
existing MPLS standards.</t>
<t>Mechanisms and capabilities MUST be able to interoperate with
existing IETF MPLS <xref target="RFC3031"></xref> and IETF PWE3
<xref target="RFC3985"></xref> control and data planes where
appropriate.<list style="letters">
<t>Data plane interoperability MUST NOT require a gateway
function.</t>
</list></t>
<t>MPLS-TP and its interfaces, both internal and external, MUST be
sufficiently well-defined that interworking equipment supplied by
multiple vendors will be possible both within a single domain, and
between domains.</t>
<t>MPLS-TP MUST be a connection-oriented packet switching
technology with traffic engineering capabilities that allow
deterministic control of the use of network resources.</t>
<t>MPLS-TP MUST support traffic engineered point to point (P2P)
and point to multipoint (P2MP) transport paths.</t>
<t>MPLS-TP MUST support unidirectional, co-routed bidirectional
and associated bidirectional point-to-point transport paths.</t>
<t>MPLS-TP MUST support unidirectional point-to-multipoint
transport paths.</t>
<t>The end points of a co-routed bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse
paths used to support the bidirectional service.</t>
<t>All nodes on the path of a co-routed bidirectional transport
path in the same (sub-)layer as the path MUST be aware of the
pairing relationship of the forward and the backward directions of
the transport path.</t>
<t>The end points of an associated bidirectional transport path
MUST be aware of the pairing relationship of the forward and
reverse paths used to support the bidirectional service.</t>
<t>Nodes on the path of an associated bidirectional transport path
where both the forward and backward directions transit the same
node in the same (sub-)layer as the path SHOULD be aware of the
pairing relationship of the forward and the backward directions of
the transport path.</t>
<t>MPLS-TP MUST support bidirectional transport paths with
symmetric bandwidth requirements, i.e. the amount of reserved
bandwidth is the same between the forward and backward
directions.</t>
<t>MPLS-TP MUST support bidirectional transport paths with
asymmetric bandwidth requirements, i.e. the amount of reserved
bandwidth differs between the forward and backward directions.</t>
<t>MPLS-TP MUST support the logical separation of the control and
management planes from the data plane.</t>
<t>MPLS-TP MUST support the physical separation of the control and
management planes from the data plane.</t>
<t>MPLS-TP MUST support static provisioning of transport paths via
the management plane.</t>
<t>A solution MUST be defined to support dynamic provisioning and
restoration of MPLS-TP transport paths via a control plane.</t>
<t>Static provisioning MUST NOT depend on the presence of any
element of a control plane.</t>
<t>MPLS-TP MUST support the co-existence of statically and
dynamically provisioned/managed MPLS-TP transport paths within the
same layer network or domain.</t>
<t>Mechanisms in an MPLS-TP layer network that satisfy functional
requirements that are common to general transport layer networks
(i.e., independent of technology) SHOULD be operable in a way that
is similar to the way the equivalent mechanisms are operated in
other transport layer technologies.</t>
<t>MPLS-TP MUST support the capability for network operation
(including OAM and recovery) via the management plane (without the
use of any control plane protocols).</t>
<t>The MPLS-TP data plane MUST be capable of <list style="letters">
<t>forwarding data independent of the control or management
plane used to configure and operate the MPLS-TP layer
network.</t>
<t>taking recovery actions independent of the control or
management plane used to configure the MPLS-TP layer
network.</t>
<t>operating normally (i.e. forwarding, OAM and protection
MUST continue to operate) if the management plane or control
plane that configured the transport paths fails.</t>
</list></t>
<t>MPLS-TP MUST support mechanisms to avoid or minimize traffic
impact (e.g. packet delay, reordering and loss) during network
reconfiguration.</t>
<t>MPLS-TP MUST support transport paths through multiple
homogeneous domains.</t>
<t>MPLS-TP SHOULD support transport paths through multiple
non-homogeneous domains.</t>
<t>MPLS-TP MUST NOT dictate the deployment of any particular
network topology either physical or logical, however:<list
style="letters">
<t>It MUST be possible to deploy MPLS-TP in rings.</t>
<t>It MUST be possible to deploy MPLS-TP in arbitrarily
interconnected rings with one or two points of
interconnection.</t>
<t>MPLS-TP MUST support rings of at least 16 nodes in order to
support the upgrade of existing TDM rings to MPLS-TP. MPLS-TP
SHOULD support rings with more than 16 nodes.</t>
</list></t>
<t>MPLS-TP MUST be able to scale at least as well as existing
transport technologies with growing and increasingly complex
network topologies as well as with increasing bandwidth demands,
number of customers, and number of services.</t>
<t>MPLS-TP SHOULD support mechanisms to safeguard against the
provisioning of transport paths which contain forwarding
loops.</t>
</list></t>
</section>
<section title="Layering requirements">
<t><list counter="Requirements" style="format %d">
<t>A generic and extensible solution MUST be provided to support
the transport of one or more client layer networks (e.g. MPLS-TP,
IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer
network.</t>
<t>A generic and extensible solution MUST be provided to support
the transport of MPLS-TP transport paths over one or more server
layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
Requirements for bandwidth management within a server layer
network are outside the scope of this document.</t>
<t>In an environment where an MPLS-TP layer network is supporting
a client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server or
client layer network.<list style="letters">
<t>The server layer MUST guarantee that the traffic loading
imposed by other clients does not cause the transport service
provided to the MPLS-TP layer to fall below the agreed level.
Mechanisms to achieve this are outside the scope of these
requirements.</t>
<t>It MUST be possible to isolate the control and management
planes of the MPLS-TP layer network from the control and
management planes of the client and server layer networks.</t>
</list></t>
<t>A solution MUST be provided to support the transport of a
client MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP
layer network.<list style="letters">
<t>The level of co-ordination required between the client and
server MPLS(-TP) layer networks MUST be minimized (preferably
no co-ordination will be required).</t>
<t>The MPLS(-TP) server layer network MUST be capable of
transporting the complete set of packets generated by the
client MPLS(-TP) layer network, which may contain packets that
are not MPLS packets (e.g. IP or CNLS packets used by the
control/management plane of the client MPLS(-TP) layer
network).</t>
</list></t>
<t>It MUST be possible to operate the layers of a multi-layer
network that includes an MPLS-TP layer autonomously.</t>
</list></t>
<t>The above are not only technology requirements, but also
operational requirements. Different administrative groups may be
responsible for the same layer network or different layer
networks.</t>
<t><list counter="Requirements" style="format %d">
<t>It MUST be possible to hide MPLS-TP layer network addressing
and other information (e.g. topology) from client layer networks.
However, it SHOULD be possible, at the option of the operator, to
leak a limited amount of summarized information (such as SRLGs or
reachability) between layers.</t>
</list></t>
</section>
<section title="Data plane requirements">
<t><list counter="Requirements" style="format %d">
<t>It MUST be possible to operate and configure the MPLS-TP data
plane without any IP forwarding capability in the MPLS-TP data
plane. i.e. the data plane only operates on the MPLS label.</t>
<t>It MUST be possible for the end points of an MPLS-TP transport
path that is carrying an aggregate of client transport paths to be
able to decompose the aggregate transport path into its component
client transport paths.</t>
<t>A transport path on a link MUST be uniquely identifiable by a
single label on that link.</t>
<t>A transport path's source MUST be identifiable at its
destination within its layer network.</t>
<t>MPLS-TP MUST be capable of using P2MP server (sub-)layer
capabilities as well as P2P server (sub-)layer capabilities when
supporting P2MP MPLS-TP transport paths.</t>
<t>MPLS-TP MUST be extensible in order to accommodate new types of
client layer networks and services.</t>
<t>MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth associated with a transport path to be increased without
impacting the existing traffic on that transport path provided
enough resources are available.</t>
<t>MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth of a transport path to be decreased without impacting
the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved bandwidth
following the decrease.</t>
<t>MPLS-TP MUST support mechanisms which ensure the integrity of
the transported customer's service traffic as required by its
associated SLA. Loss of integrity may be defined as packet
corruption, re-ordering or loss during normal network
conditions.</t>
<t>MPLS-TP MUST support mechanisms to detect when loss of
integrity of the transported customer's service traffic has
occurred.</t>
<t>MPLS-TP MUST support an unambiguous and reliable means of
distinguishing users' (client) packets from MPLS-TP control
packets (e.g. control plane, management plane, OAM and protection
switching packets).</t>
</list></t>
</section>
<section title="Control plane requirements">
<t>This section defines the requirements that apply to an MPLS-TP
control plane. Note that it MUST be possible to operate an MPLS-TP
network without using a control plane.</t>
<t>The ITU-T has defined an architecture for Automatically Switched
Optical Networks (ASON) in <xref target="ITU.G8080.2006">G.8080</xref>
and <xref target="ITU.G8080.2008">G.8080 Amd1</xref>. The control
plane for MPLS-TP MUST fit within the ASON architecture.</t>
<t>An interpretation of the ASON signaling and routing requirements in
the context of GMPLS can be found in <xref target="RFC4139"></xref>
and <xref target="RFC4258"></xref>.</t>
<t>Additionally:</t>
<t><list counter="Requirements" style="format %d">
<t>The MPLS–TP control plane MUST support control plane
topology and data plane topology independence. As a consequence a
failure of the control plane does not imply that there has also
been a failure of the data plane.</t>
<t>The MPLS-TP control plane MUST be able to be operated
independent of any particular client or server layer control
plane.</t>
<t>MPLS-TP SHOULD define a solution to support an integrated
control plane encompassing MPLS-TP together with its server and
client layer networks when these layer networks belong to the same
administrative domain.</t>
<t>The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e.,
unidirectional P2P, associated bidirectional P2P, co-routed
bidirectional P2P, unidirectional P2MP) including configuration of
protection functions and any associated maintenance functions.</t>
<t>The MPLS-TP control plane MUST support the configuration and
modification of OAM maintenance points as well as the
activation/deactivation of OAM when the transport path or
transport service is established or modified.</t>
<t>An MPLS-TP control plane MUST support operation of the recovery
functions described in Section 2.8.</t>
<t>An MPLS-TP control plane MUST scale gracefully to support a
large number of transport paths, nodes and links.</t>
<t>If a control plane is used for MPLS-TP, following a control
plane failure, the control plane MUST be capable of restarting and
relearning its previous state without impacting forwarding.</t>
<t>An MPLS-TP control plane MUST provide a mechanism for dynamic
ownership transfer of the control of MPLS-TP transport paths from
the management plane to the control plane and vice versa. The
number of reconfigurations required in the data plane MUST be
minimized (preferably no data plane reconfiguration will be
required).</t>
</list></t>
</section>
<section title="Network Management requirements">
<t>For requirements related to network management functionality
(Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP
Network Management requirements document <xref
target="I-D.ietf-mpls-tp-nm-req"></xref>.</t>
</section>
<section title="Operation, Administration and Maintenance (OAM) requirements">
<t>For requirements related to OAM functionality for MPLS-TP, see the
MPLS-TP OAM requirements document <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>.</t>
</section>
<section title="Network performance monitoring requirements">
<t>For requirements related to performance monitoring functionality
for MPLS-TP, see the MPLS-TP OAM requirements document <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>.</t>
</section>
<section anchor="recovery" title="Recovery requirements">
<t>Network survivability plays a critical role in the delivery of
reliable services. Network availability is a significant contributor
to revenue and profit. Service guarantees in the form of SLAs require
a resilient network that rapidly detects facility or node failures and
restores network operation in accordance with the terms of the
SLA.</t>
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP MUST provide protection and restoration
mechanisms.<list style="letters">
<t>MPLS-TP recovery techniques SHOULD be identical (or as
similar as possible) to those already used in existing
transport networks to simplify implementation and operations.
However, this MUST NOT override any other requirement.</t>
<t>Recovery techniques used for P2P and P2MP SHOULD be
identical to simplify implementation and operation. However,
this MUST NOT override any other requirement.</t>
</list></t>
<t>MPLS-TP recovery mechanisms MUST be applicable at various
levels throughout the network including support for link,
transport path, segment, concatenated segment and end to end
recovery.</t>
<t>MPLS-TP recovery paths MUST meet the SLA protection objectives
of the service.<list style="letters">
<t>MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
times from the moment of fault detection in networks with
spans less than 1200 km.</t>
<t>For protection it MUST be possible to require protection of
100% of the traffic on the protected path.</t>
<t>Recovery MUST meet SLA requirements over multiple
domains.</t>
</list></t>
<t>Recovery objectives SHOULD be configurable per transport
path.</t>
<t>The recovery mechanisms SHOULD be applicable to any
topology.</t>
<t>The recovery mechanisms MUST support the means to operate in
synergy with (including coordination of timing) the recovery
mechanisms present in any client or server transport networks (for
example, Ethernet, SDH, OTN, WDM) to avoid race conditions between
the layers.</t>
<t>MPLS-TP recovery and reversion mechanisms MUST prevent frequent
operation of recovery in the event of an intermittent defect.</t>
</list></t>
<section title="Data plane behavior requirements">
<t>General protection and survivability requirements are expressed
in terms of the behavior in the data plane.</t>
<section title="Protection">
<t>Note: Only nodes that are aware of the pairing relationship
between the forward and backward directions of an associated
bidirectional transport path can be used as end points to protect
all or part of that transport path.<list counter="Requirements"
style="format %d">
<t>It MUST be possible to provide protection for the MPLS-TP
data plane without any IP forwarding capability in the MPLS-TP
data plane. i.e. the data plane only operates on the MPLS
label.</t>
<t>MPLS-TP protection mechanisms MUST support revertive and
non-revertive behavior.</t>
<t>MPLS-TP MUST support 1+1 protection.<list style="letters">
<t>Bidirectional 1+1 protection for P2P connectivity MUST
be supported.</t>
<t>Unidirectional 1+1 protection for P2P connectivity MUST
be supported.</t>
<t>Unidirectional 1+1 protection for P2MP connectivity
MUST be supported.</t>
</list></t>
<t>MPLS-TP MUST support the ability to share protection
resources amongst a number of transport paths.</t>
<t>MPLS-TP MUST support 1:n protection (including 1:1
protection).<list style="letters">
<t>Bidirectional 1:n protection for P2P connectivity MUST
be supported, and SHOULD be the default behavior for 1:n
protection.</t>
<t>Unidirectional 1:n protection for P2MP connectivity
MUST be supported.</t>
<t>Unidirectional 1:n protection for P2P connectivity is
not required and MAY be omitted from the MPLS-TP
specifications.</t>
<t>The action of protection switching MUST NOT cause the
user data to enter an uncontrolled loop. The protection
switching system MAY cause traffic to pass over a given
link more than once, but it must do so in a controlled way
such that uncontrolled loops do not form.</t>
</list></t>
</list>Note: Support for extra traffic (as defined in <xref
target="RFC4427"></xref>) is not required in MPLS-TP and MAY be
omitted from the MPLS-TP specifications.</t>
</section>
<section title="Sharing of protection resources">
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
recovery.</t>
<t>MPLS-TP MUST support sharing of protection resources such
that protection paths that are known not to be required
concurrently can share the same resources.</t>
</list></t>
</section>
</section>
<section title="Restoration">
<t><list counter="Requirements" style="format %d">
<t>The restoration transport path MUST be able to share
resources with the transport path being replaced (sometimes
known as soft rerouting).</t>
<t>Restoration priority MUST be supported so that an
implementation can determine the order in which transport paths
should be restored (to minimize service restoration time as well
as to gain access to available spare capacity on the best
paths).</t>
<t>Preemption priority MUST be supported to allow restoration to
displace other transport paths in the event of resource
constraint.</t>
<t>MPLS-TP restoration mechanisms MUST support revertive and
non-revertive behavior.</t>
</list></t>
</section>
<section title="Triggers for protection, restoration, and reversion">
<t>Recovery actions may be triggered from different places as
follows:<list counter="Requirements" style="format %d">
<t>MPLS-TP MUST support physical layer fault indication
triggers.</t>
<t>MPLS-TP MUST support OAM-based triggers.</t>
<t>MPLS-TP MUST support management plane triggers (e.g., forced
switch, etc.).</t>
<t>There MUST be a mechanism to allow administrative recovery
actions to be distinguished from recovery actions initiated by
other triggers.</t>
<t>Where a control plane is present, MPLS-TP SHOULD support
control plane restoration triggers.</t>
<t>MPLS-TP protection mechanisms MUST support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative
requests and requests due to link/node failures).</t>
</list></t>
</section>
<section title="Management plane operation of protection and restoration">
<t>All functions described here are for control by the
operator.<list counter="Requirements" style="format %d">
<t>It MUST be possible to configure protection paths and
protection-to-working path relationships (sometimes known as
protection groups).</t>
<t>There MUST be support for pre-calculation of recovery
paths.</t>
<t>There MUST be support for pre-provisioning of recovery
paths.</t>
<t>The external controls as defined in <xref
target="RFC4427"></xref> MUST be supported.<list style="letters">
<t>External controls overruled by higher priority requests
(e.g., administrative requests and requests due to link/node
failures) or unable to be signaled to the remote end (e.g.
because of a protection state coordination fail) MUST be
dropped.</t>
</list></t>
<t>It MUST be possible to test and validate any
protection/restoration mechanisms and protocols:<list
style="letters">
<t>Including the integrity of the protection/recovery
transport path.</t>
<t>Without triggering the actual protection/restoration.</t>
<t>While the working path is in service.</t>
<t>While the working path is out of service.</t>
</list></t>
<t>Restoration resources MAY be pre-planned and selected a
priori, or computed after failure occurrence.</t>
<t>When preemption is supported for restoration purposes, it
MUST be possible for the operator to configure it.</t>
<t>The management plane MUST provide indications of protection
events and triggers.</t>
<t>The management plane MUST allow the current protection status
of all transport paths to be determined.</t>
</list></t>
</section>
<section title="Control plane and in-band OAM operation of recovery">
<t><list counter="Requirements" style="format %d">
<t>The MPLS-TP control plane (which is not mandatory in an
MPLS-TP implementation) MUST be capable of supporting: <list
style="letters">
<t>establishment and maintenance of all recovery entities
and functions</t>
<t>signaling of administrative control</t>
<t>protection state coordination (PSC). Since control plane
network topology is independent from the data plane network
topology, the PSC supported by the MPLS-TP control plane MAY
run on resources different than the data plane resources
handled within the recovery mechanism (e.g. backup).</t>
</list></t>
<t>In-band OAM MUST be capable of supporting:<list
style="letters">
<t>signaling of administrative control</t>
<t>protection state coordination (PSC). Since in-band OAM
tools share the data plane with the carried transport
service, in order to optimize the usage of network
resources, the PSC supported by in-band OAM MUST run on
protection resources.</t>
</list></t>
</list></t>
</section>
<section anchor="topologyspecific"
title="Topology-specific recovery mechanisms">
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP MAY support recovery mechanisms that are optimized
for specific network topologies. These mechanisms MUST be
interoperable with the mechanisms defined for arbitrary topology
(mesh) networks to enable protection of end-to-end transport
paths.</t>
</list></t>
<section anchor="ringprotection" title="Ring protection">
<t>Several service providers have expressed a high level of
interest in operating MPLS-TP in ring topologies and require a
high level of survivability function in these topologies. The
requirements listed below have been collected from these service
providers and from the ITU-T.</t>
<t>The main objective in considering a specific topology (such as
a ring) is to determine whether it is possible to optimize any
mechanisms such that the performance of those mechanisms within
the topology is significantly better than the performance of the
generic mechanisms in the same topology. The benefits of such
optimizations are traded against the costs of developing,
implementing, deploying, and operating the additional optimized
mechanisms noting that the generic mechanisms MUST continue to be
supported.</t>
<t>Within the context of recovery in MPLS-TP networks, the
optimization criteria considered in ring topologies are as
follows: <list style="letters">
<t>Minimize the number of OAM entities that are needed to
trigger the recovery operation – less than are required
by other recovery mechanisms.</t>
<t>Minimize the number of elements of recovery in the ring
– less than are required by other recovery
mechanisms.</t>
<t>Minimize the number of labels required for the protection
paths across the ring – less than are required by other
recovery mechanisms.</t>
<t>Minimize the amount of control and management plane
transactions during a maintenance operation (e.g., ring
upgrade) – less than are required by other recovery
mechanisms.</t>
<t>When a control plane is supported, minimize the impact on
signaling and routing information exchange during protection -
less than are required by other recovery mechanisms.</t>
</list></t>
<t>It may be observed that the requirements in <xref
target="ringprotection"></xref> are fully compatible with the
generic requirements expressed in <xref target="recovery"></xref>
through <xref target="topologyspecific"></xref> inclusive, and
that no requirements that are specific to ring topologies have
been identified.</t>
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP MUST include recovery mechanisms that operate in
any single ring supported in MPLS-TP, and continue to operate
within the single rings even when the rings are
interconnected.</t>
<t>When a network is constructed from interconnected rings,
MPLS-TP MUST support recovery mechanisms that protect user
data that traverses more than one ring. This includes the
possibility of failure of the ring-interconnect nodes and
links.</t>
<t>MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths.</t>
<t>MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths.</t>
<t>MPLS-TP 1+1 and 1:1 protection in a ring MUST support
switching time within 50 ms from the moment of fault detection
in a network with a 16 nodes ring with less than 1200 km of
fiber.</t>
<t>The protection switching time in a ring MUST be independent
of the number of LSPs crossing the ring.</t>
<t>The configuration and operation of recovery mechanisms in a
ring MUST scale well with: <list style="letters">
<t>the number of transport paths (must be better than
linear scaling)</t>
<t>the number of nodes on the ring (must be at least as
good as linear scaling)</t>
<t>the number of ring interconnects (must be at least as
good as linear scaling)</t>
</list></t>
<t>Recovery techniques used in a ring MUST NOT prevent the
ring from being connected to a general MPLS-TP network in any
arbitrary way, and MUST NOT prevent the operation of recovery
techniques in the rest of the network.</t>
<t>Recovery techniques in a ring SHOULD be identical (or as
similar as possible) to those in general transport networks to
simplify implementation and operations. However, this MUST NOT
override any other requirement.</t>
<t>Recovery techniques in logical and physical rings SHOULD be
identical to simplify implementation and operation. However,
this MUST NOT override any other requirement.</t>
<t>The default recovery scheme in a ring MUST be bidirectional
recovery in order to simplify the recovery operation.</t>
<t>The recovery mechanism in a ring MUST support revertive
switching, which MUST be the default behavior. This allows
optimization of the use of the ring resources, and restores
the preferred quality conditions for normal traffic (e.g.,
delay) when the recovery mechanism is no longer needed.</t>
<t>The recovery mechanisms in a ring MUST support ways to
allow administrative protection switching, to be distinguished
from protection switching initiated by other triggers.</t>
<t>It MUST be possible to lockout (disable) protection
mechanisms on selected links (spans) in a ring (depending on
operator’s need). This may require lockout mechanisms to
be applied to intermediate nodes within a transport path.</t>
</list></t>
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP recovery mechanisms in a ring:<list style="letters">
<t>MUST include a mechanism to allow an implementation to
handle (including the coordination of) coexisting requests
or triggers (i.e., multiple requests – not
necessarily arriving simultaneously and located anywhere
in the ring) for protection switching based on priority.
Note that such coordination is the ring equivalent of the
definition of shared protection groups.</t>
<t>SHOULD protect against multiple failures</t>
</list></t>
<t>MPLS-TP recovery and reversion mechanisms in a ring MUST
offer a way to prevent frequent operation of recovery in the
event of an intermittent defect.</t>
<t>MPLS-TP MUST support the sharing of protection bandwidth in
a ring by allowing best effort traffic.</t>
<t>MPLS-TP MUST support sharing of ring protection resources
such that protection paths that are known not to be required
concurrently can share the same resources.</t>
</list></t>
</section>
</section>
</section>
<section title="QoS requirements">
<t>Carriers require advanced traffic management capabilities to
enforce and guarantee the QoS parameters of customers’ SLAs.</t>
<t>Quality of service mechanisms are REQUIRED in an MPLS-TP network to
ensure:</t>
<t><list counter="Requirements" style="format %d">
<t>Support for differentiated services and different traffic types
with traffic class separation associated with different
traffic.</t>
<t>Enabling the provisioning and the guarantee of Service Level
Specifications (SLS), with support for hard and relative
end-to-end bandwidth guaranteed.</t>
<t>Support of services, which are sensitive to jitter and
delay.</t>
<t>Guarantee of fair access, within a particular class, to shared
resources.</t>
<t>Guaranteed resources for in-band control and management plane
traffic regardless of the amount of data plane traffic.</t>
<t>Carriers are provided with the capability to efficiently
support service demands over the MPLS-TP network. This MUST
include support for a flexible bandwidth allocation scheme.</t>
</list></t>
</section>
<section title="Security requirements">
<t>For a description of the security threats relevant in the context
of MPLS and GMPLS and the defensive techniques to combat those threats
see the Security Framework for MPLS & GMPLS Networks <xref
target="I-D.ietf-mpls-mpls-and-gmpls-security-framework"></xref>.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>See Section 2.10.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in the IETF, and the
T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and
specification of MPLS Transport Profile.</t>
<t>The authors would also like to thank Loa Andersson, Dieter Beller,
Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Fulignoli,
Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van Helvoort,
Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Malis, Alan
McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi Ohta, Tom
Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski,
Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve Varma and
Maarten Vissers for their comments and enhancements to the text.</t>
<t>An ad hoc discussion group consisting of Stewart Bryant, Italo Busi,
Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Feng
Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher provided
valuable input to the requirements for deployment and survivability in
ring topologies.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion reference.RFC.2119.xml. -->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
type="TXT" />
<format octets="16553"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5703"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<!-- End inclusion reference.RFC.2119.xml. -->
<!--Begin inclusion reference.RFC.3031.xml. -->
<reference anchor="RFC3031">
<front>
<title abbrev="MPLS Architecture">Multiprotocol Label Switching
Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<author fullname="A. Viswanathan" initials="A."
surname="Viswanathan">
<organization></organization>
</author>
<author fullname="R. Callon" initials="R." surname="Callon">
<organization></organization>
</author>
<date month="January" year="2001" />
<abstract>
<t>This document specifies the architecture for Multiprotocol
Label Switching (MPLS). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031" />
<format octets="147175"
target="ftp://ftp.isi.edu/in-notes/rfc3031.txt" type="TXT" />
</reference>
<!-- End inclusion reference.RFC.3031.xml. -->
<!--Begin inclusion reference.RFC.3985.xml. -->
<reference anchor="RFC3985">
<front>
<title abbrev="PWE3 Architecture">Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture</title>
<author fullname="S. Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="P. Pate" initials="P." surname="Pate">
<organization></organization>
</author>
<date month="March" year="2005" />
<abstract>
<t>This document describes an architecture for Pseudo Wire
Emulation Edge-to-Edge (PWE3). It discusses the emulation of
services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH
over packet switched networks (PSNs) using IP or MPLS. It presents
the architectural framework for pseudo wires (PWs), defines
terminology, and specifies the various protocol elements and their
functions. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3985" />
<format octets="95062" target="ftp://ftp.isi.edu/in-notes/rfc3985.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.3985.xml. -->
<?rfc include="reference.RFC.4929"?>
<!--Begin inclusion reference.ITU.G805.2000.xml. -->
<reference anchor="ITU.G805.2000">
<front>
<title abbrev="G.805">Generic functional architecture of transport
networks</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="March" year="2000" />
<abstract>
<t>This Recommendation describes the functional architecture of
transport networks in a technology independent way. The generic
functional architecture may be used as the basis for a harmonized
set of functional architecture Recommendations for ATM, SDH, PDH
transport networks, and a corresponding set of Recommendations for
management, performance analysis and equipment specification.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.805" />
</reference>
<!-- End inclusion reference.ITU.G805.2000.xml.-->
<!--Begin inclusion reference.ITU.G8080.2006.xml. -->
<reference anchor="ITU.G8080.2006">
<front>
<title abbrev="ASON architecture">Architecture for the automatically
switched optical network (ASON)</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="June" year="2006" />
<abstract>
<t>This Recommendation describes the functional architecture of
transport networks in a technology independent way. The generic
functional architecture may be used as the basis for a harmonized
set of functional architecture Recommendations for ATM, SDH, PDH
transport networks, and a corresponding set of Recommendations for
management, performance analysis and equipment specification.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.8080" />
</reference>
<!-- End inclusion reference.ITU.G8080.2006.xml.-->
<!--Begin inclusion reference.ITU.G8080.2008.xml. -->
<reference anchor="ITU.G8080.2008">
<front>
<title abbrev="ASON architecture Amendment 1">Architecture for the
automatically switched optical network (ASON) Amendment 1</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="March" year="2008" />
<abstract>
<t>This Recommendation describes the functional architecture of
transport networks in a technology independent way. The generic
functional architecture may be used as the basis for a harmonized
set of functional architecture Recommendations for ATM, SDH, PDH
transport networks, and a corresponding set of Recommendations for
management, performance analysis and equipment specification.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.8080 Amendment 1" />
</reference>
<!-- End inclusion reference.ITU.G8080.2008.xml.-->
</references>
<references title="Informative References">
<!--Begin inclusion reference.RFC.4139.xml. -->
<reference anchor="RFC4139">
<front>
<title abbrev="ASON Signaling Requirements">Requirements for
Generalized MPLS (GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)</title>
<author fullname="D. Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<author fullname="J. Drake" initials="J." surname="Drake">
<organization></organization>
</author>
<author fullname="J. Ash" initials="J." surname="Ash">
<organization></organization>
</author>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<author fullname="L. Ong" initials="L." surname="Ong">
<organization></organization>
</author>
<date month="July" year="2005" />
<abstract>
<t>The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols has been defined to control different switching
technologies and different applications. These include support for
requesting Time Division Multiplexing (TDM) connections, including
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
(SDH) and Optical Transport Networks (OTNs).</t>
<t>This document concentrates on the signaling aspects of the
GMPLS suite of protocols. It identifies the features to be covered
by the GMPLS signaling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON). This document
provides a problem statement and additional requirements for the
GMPLS signaling protocol to support the ASON functionality. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4139" />
<format octets="36660" target="ftp://ftp.isi.edu/in-notes/rfc4139.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4139.xml. -->
<!--Begin inclusion reference.RFC.4258.xml. -->
<reference anchor="RFC4258">
<front>
<title abbrev="ASON Routing Requirements">Requirements for
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)</title>
<author fullname="D. Brungard" initials="D." surname="Brungard">
<organization></organization>
</author>
<date month="November" year="2005" />
<abstract>
<t>The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols has been defined to control different switching
technologies as well as different applications. These include
support for requesting Time Division Multiplexing (TDM)
connections including Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport
Networks (OTNs).</t>
<t>This document concentrates on the routing requirements placed
on the GMPLS suite of protocols in order to support the
capabilities and functionalities of an Automatically Switched
Optical Network (ASON) as defined by the ITU-T. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4258" />
<format octets="48558" target="ftp://ftp.isi.edu/in-notes/rfc4258.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4258.xml. -->
<!--Begin inclusion reference.RFC.4397.xml. -->
<reference anchor="RFC4397">
<front>
<title abbrev="ASON/GMPLS terminology lexicography">A Lexicography
for the Interpretation of Generalized Multiprotocol Label Switching
(GMPLS) Terminology within the Context of the ITU-T's Automatically
Switched Optical Network (ASON) Architecture</title>
<author fullname="I. Bryskin" initials="I." surname="Bryskin">
<organization></organization>
</author>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="February" year="2006" />
<abstract>
<t>The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols has been defined to control different switching
technologies as well as different applications. These include
support for requesting Time Division Multiplexing (TDM)
connections including Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport
Networks (OTNs).</t>
<t>This document concentrates on the routing requirements placed
on the GMPLS suite of protocols in order to support the
capabilities and functionalities of an Automatically Switched
Optical Network (ASON) as defined by the ITU-T. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4397" />
<format octets="40331" target="ftp://ftp.isi.edu/in-notes/rfc4397.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4397.xml. -->
<!--Begin inclusion reference.RFC.4427.xml. -->
<reference anchor="RFC4427">
<front>
<title abbrev="Recovery Terminology">Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Label
Switching (GMPLS)</title>
<author fullname="E. Mannie" initials="E." surname="Mannie">
<organization></organization>
</author>
<author fullname="D. Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<date month="March" year="2006" />
<abstract>
<t>This document defines a common terminology for Generalized
Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms
(i.e., protection and restoration). The terminology is independent
of the underlying transport technologies covered by GMPLS. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4427" />
<format octets="43842" target="ftp://ftp.isi.edu/in-notes/rfc4427.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4427.xml.-->
<!--Begin inclusion reference.I-D.ietf-mpls-mpls-and-gmpls-security-framework.xml. -->
<reference anchor="I-D.ietf-mpls-mpls-and-gmpls-security-framework">
<front>
<title
abbrev="Security Framework for MPLS & GMPLS Networks">Security
Framework for MPLS and GMPLS Networks</title>
<author fullname="L. Fang" initials="L." surname="Fang">
<organization></organization>
</author>
<author fullname="M. Behringer" initials="M." surname="Behringer">
<organization></organization>
</author>
<date month="November" year="2008" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mpls-mpls-and-gmpls-security-framework-05" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mpls-mpls-and-gmpls-security-framework-05"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.ietf-mpls-mpls-and-gmpls-security-framework.xml. -->
<!--Begin inclusion reference.I-D.ietf-mpls-tp-nm-req.xml. -->
<reference anchor="I-D.ietf-mpls-tp-nm-req">
<front>
<title abbrev="MPLS-TP NM requirements">MPLS TP Network Management
Requirements</title>
<author fullname="H. Lam" initials="H." surname="Lam">
<organization></organization>
</author>
<author fullname="S. Mansfield" initials="S." surname="Mansfield">
<organization></organization>
</author>
<author fullname="E. Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="April" year="2009" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-tp-nm-req-01" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-00.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.ietf-mpls-tp-nm-req.xml. -->
<!--Begin inclusion reference.I-D.helvoort-mpls-tp-rosetta-stone.xml. -->
<reference anchor="I-D.helvoort-mpls-tp-rosetta-stone">
<front>
<title abbrev="MPLS-TP Terminology Thesaurus">A Thesaurus for the
Terminology used in Multiprotocol Label Switching Transport Profile
(MPLS-TP) drafts/RFCs and ITU-T's Transport Network
Recommendations.</title>
<author fullname="H. van Helvoort" initials="H."
surname="van Helvoort">
<organization></organization>
</author>
<author fullname="L. Andersson" initials="L." surname="Andersson">
<organization></organization>
</author>
<author fullname="N. Sprecher" initials="N." surname="Sprecher">
<organization></organization>
</author>
<date day="" month="March" year="2009" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-helvoort-mpls-tp-rosetta-stone-00" />
<format target="http://www.ietf.org/internet-drafts/draft-helvoort-mpls-tp-rosetta-stone-00.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.helvoort-mpls-tp-rosetta-stone.xml.-->
<!--Begin inclusion reference.I-D.ietf-mpls-tp-oam-requirements.xml. -->
<reference anchor="I-D.ietf-mpls-tp-oam-requirements">
<front>
<title abbrev="MPLS-TP NM requirements">Requirements for OAM in MPLS
Transport Networks</title>
<author fullname="M. Vigoureux" initials="M." surname="Vigoureux">
<organization></organization>
</author>
<author fullname="D. Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<author fullname="M. Betts" initials="M." surname="Betts">
<organization></organization>
</author>
<date month="November" year="2008" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-mpls-tp-oam-requirements-01" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.ietf-mpls-tp-oam-requirements.xml. -->
<!--Begin inclusion reference.I-D.ietf-pwe3-ms-pw-arch.xml. -->
<reference anchor="I-D.ietf-pwe3-ms-pw-arch">
<front>
<title abbrev="MPLS-TP NM requirements">Requirements for OAM in MPLS
Transport Networks</title>
<author fullname="M. Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="S. Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="September" year="2008" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-pwe3-ms-pw-arch-06" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-arch-06.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.ietf-pwe3-ms-pw-arch.xml. -->
<!--Begin inclusion reference.ITU.Y1401.2008.xml. -->
<reference anchor="ITU.Y1401.2008">
<front>
<title abbrev="Y.1401">Principles of interworking</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="February" year="2008" />
<abstract>
<t>This Recommendation provides an architectural framework and
general principles for transport stratum interworking in an NGN
environment. It describes client/server and peer-partition
interworking.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="Recommendation Y.1401" />
</reference>
<!-- End inclusion reference.ITU.Y1401.2008.xml. -->
<!--Begin inclusion reference.ITU.Y2611.2006.xml. -->
<reference anchor="ITU.Y2611.2006">
<front>
<title abbrev="Y.2611">High-level architecture of future
packet-based networks</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="December" year="2006" />
<abstract>
<t>ITU-T Recommendation Y.2611 specifies a high-level architecture
for future packet-based networks (FPBNs). This Recommendation also
specifies the relationship between an FPBN and the NGN strata and
the interfaces in an FPBN.</t>
<t>In order to be able to provide a full suite of services
(examples of which include data, video and voice telephony
services) to their customers, operators may need to utilize both
connectionless packet switched (cl-ps) and connection-oriented
packet-switched (co-ps) transport modes. This is because each mode
is well suited to the transport of some services and not so well
suited to the transport of others.</t>
<t>FPBNs provide the topmost layer(s) of the transport stratum as
defined in ITU-T Recommendation Y.2011. The services mentioned
above form part of the service stratum as defined in ITU-T
Recommendation Y.2011.</t>
</abstract>
</front>
<seriesInfo name="ITU-T" value="Recommendation Y.2611" />
</reference>
<!-- End inclusion reference.ITU.Y2611.2006.xml. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:20:47 |