One document matched: draft-ietf-mpls-tp-requirements-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-mpls-tp-requirements-04"
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 day="5" month="February" year="2009" />
<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 architecture 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 architecture
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>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>
</note>
</front>
<middle>
<section title="Introduction">
<t>For many years, transport networks (e.g. Synchronous Optical
Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided
carriers with a high benchmark for reliability and operational
simplicity. With the accelerating growth and penetration of:<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 QoS requirements.</t>
</list>Carriers are in need of technologies capable of efficiently
supporting packet-based services and applications on their transport
networks. 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>Carriers are considering migrating or evolving to packet transport
networks in order to reduce their costs and to improve their ability to
support services with guaranteed Service Level Agreements (SLAs). For
carriers it is important that migrating from their existing transport
networks to packet transport networks should not involve dramatic
changes in network operation, should not necessitate extensive
retraining, and should not require major changes to existing work
practices. The aim is to preserve the look-and-feel to which carriers
have become accustomed in deploying their transport networks, while
providing common, multi-layer operations, resiliency, control and
management for packet, circuit and lambda transport networks.</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 (Operations Support System (OSS) based) or dynamic
(control plane) provisioning of deterministic, protected and secured
services and their associated resources.</t>
<t>Carriers will still need to cope with legacy networks (which are
composed of many layers and technologies), thus the packet transport
network should interwork as appropriate with other packet and transport
networks (both horizontally and vertically). Vertical interworking is
also known as client/server or network interworking. Horizontal
interworking is also known as peer-partition or service interworking.
For more details on each type of interworking and some of the issues
that may arise (especially with horizontal interworking) see <xref
target="ITU.Y1401.2008">Y.1401</xref>.</t>
<t>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 is therefore the need to define an
MPLS Transport Profile (MPLS-TP) in order to support the capabilities
and functionalities needed for packet transport network services and
operations through combining the packet experience of MPLS with the
operational experience of existing transport networks.</t>
<t>MPLS-TP will enable the migration of transport networks to a
packet-based network 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 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-IETF effort to include an
MPLS Transport Profile within the IETF MPLS architecture 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 architecture
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 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 protocols for dynamic configuration.</t>
<section title="Terminology">
<t>Note: Mapping between the terms in this section and ITU-T
terminology will be described in a subsequent document.</t>
<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 may or may not follow the same route (links and nodes)
across the network.</t>
<t>Bidirectional path: A path where the forward and backward
directions follow the same route (links and nodes) across the
network.</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.</t>
<t>Co-routed bidirectional path: A bidirectional path where the
forward and backward directions follow the same route (links and
nodes) across its layer network.</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(s) 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 zero or more sublayers. 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>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 MSPL-TP
pseudowires) and physical data links that form a ring topology.</t>
<t>Path: See Transport path.</t>
<t>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>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 data 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: A section is a server layer (which may be MPLS-TP or a
different technology) which provides for encapsulation and OAM of a
MPLS-TP transport path client 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 {S|T}-PEs).</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>Tandem Connection: A tandem connection is an arbitrary part of a
transport path that can be monitored (via OAM) independently from the
end-to-end monitoring (OAM). It may be a monitored segment, a
monitored concatenated segment or any other monitored ordered sequence
of contiguous hops and/or segments (and their interconnecting nodes)
of a transport path.</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 layer network which provides point-to-point
or point-to-multipoint transport paths which are used to carry a
higher (client) layer network or aggregates of higher (client) layer
networks, for example the transport service layer. It provides for
independent OAM (of the client OAM) in the transport of the
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 which 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 title="Transport network overview">
<t>The connection (or transport path) service is the basic service
provided by a transport network. The purpose of a transport network is
to carry its clients (i.e. the stream of client PDUs or client bits)
between endpoints in the network (typically over several intermediate
nodes). These endpoints may be service switching points or service
terminating points. The connection services offered to customers are
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>Aggregation and hierarchy are beneficial for achieving scalability
and security since: <list style="numbers">
<t>They reduce the number of provisioning and forwarding states in
the network core.</t>
<t>They reduce load and the cost of implementing service assurance
and fault management.</t>
<t>Clients are 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 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. 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>Clients are first encapsulated. These encapsulated client signals
may then be aggregated into a connection for transport through the
network in order to optimize network management. Server layer OAM is
used to monitor the transport integrity of the client layer or client
aggregate. At any hop, the aggregated signals may be further
aggregated in lower layer transport network paths for transport across
intermediate shared links. The encapsulated client signals are
extracted at the edges of aggregation domains, and are either
delivered to the client or forwarded to another domain. In the core of
the network, only the server layer aggregated signals are monitored;
individual client signals are monitored at the network boundary in the
client layer network. Although the connectivity of the client of the
transport path layer may be point-to-point, point-to-multipoint or
multipoint-to-multipoint, the transport path layer itself only
provides point-to-point or point-to-multipoint transport paths which
are used to carry the client.</t>
<t>Quality-of-service mechanisms are required in the packet transport
network to ensure the prioritization of critical services, to
guarantee BW and to control jitter and delay.</t>
</section>
<section 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 the
clients include the control of forwarding, the control of resource
reservation, the control of traffic demerging, and the OAM 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 common features in order to support the
control of forwarding, resource reservation, and OAM. 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 as the 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 within
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></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 fulfil the
requirements for MPLS-TP MUST be agreed within the IETF through
the IETF consensus process and MUST re-use (as far as practically
possible) existing MPLS standards.</t>
<t>Mechanisms and capabilities MUST be able to interoperate,
without a gateway function, with existing IETF MPLS <xref
target="RFC3031"></xref> and IETF PWE3 <xref
target="RFC3985"></xref> control and data planes where
appropriate.</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 network,
and between networks.</t>
<t>MPLS-TP MUST be a connection-oriented packet switching model
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 the logical separation of the control and
management planes from the data plane.</t>
<t>MPLS-TP MUST allow 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
an OSS, i.e. via the management plane.</t>
<t>Mechanisms in an MPLS-TP network that satisfy functional
requirements that are common to general transport 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 networks.</t>
<t>Static provisioning MUST NOT depend on the presence of any
element of a control plane.</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>A solution MUST be provided to support dynamic provisioning of
MPLS-TP transport paths via a control plane.</t>
<t>The MPLS-TP data plane MUST be capable of forwarding data and
taking recovery actions independently of the control or management
plane used to operate the MPLS-TP layer network. That is, the
MPLS-TP data plane MUST continue to operate normally if the
management plane or control plane that configured the transport
paths fails.</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 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,
Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.</t>
<t>A 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 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
network.</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. 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 layers.</t>
</list></t>
</section>
<section title="Data plane requirements">
<t><list counter="Requirements" style="format %d">
<t>The identification of each transport path within its aggregate
MUST be supported.</t>
<t>A label in a particular link MUST uniquely identify the
transport path within 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 when supporting P2MP MPLS-TP transport paths (for
example context-specific labels <xref
target="RFC5331"></xref>).</t>
<t>It MUST be possible to operate and configure the MPLS-TP data
(transport) plane without any IP forwarding capability in the
MPLS-TP data plane.</t>
<t>MPLS-TP MUST support unidirectional, bidirectional and
co-routed bidirectional point-to-point transport paths.</t>
<t>The forward and backward directions of a co-routed
bidirectional transport path MUST follow the same links and nodes
within its (sub-)layer network.</t>
<t>The intermediate nodes at each (sub-)layer MUST be aware about
the pairing relationship of the forward and the backward
directions belonging to the same bidirectional transport path.</t>
<t>MPLS-TP MAY support 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 unidirectional point-to-multipoint
transport paths.</t>
<t>MPLS-TP MUST be extensible in order to accommodate new types of
client 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</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 MPLS-TP when a
control plane is deployed.</t>
<t>The ITU-T has defined an architecture for Automatically Switched
Optical and Transport Networks (ASON/ASTN) in <xref
target="ITU.G8080.2006">G.8080</xref>. The control plane for MPLS-TP
MUST fit within the ASON/ASTN architecture.</t>
<t>An interpretation of the ASON/ASTN control plane 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 pane SHOULD support control plane
topology and data plane topology independence.</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>The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (e.g.,
unidirectional and bidirectional P2P, unidirectional P2MP, etc.)
including configuration of protection functions and any associated
maintenance functions.</t>
<t>The MPLS-TP control pane 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>
</list></t>
</section>
<section title="Network Management (NM) requirements">
<t>For requirements related to NM functionality (Management Plane in
ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements
document <xref target="I-D.gray-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 management (PM) requirements">
<t>For requirements related to PM 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="Recovery & Survivability 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>The requirements in this section use the recovery terminology
defined in RFC 4427 <xref target="RFC4427"></xref>.</t>
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP MUST provide protection and restoration
mechanisms.<list style="letters">
<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, path
segment and end-to-end path, and pseudowire segment, and
end-to-end pseudowire 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 objectives SHOULD be configurable per transport
path, and SHOULD include bandwidth and QoS.</t>
</list></t>
<t>The recovery mechanisms MUST all be applicable to any
topology.</t>
<t>The recovery mechanisms MUST operate in synergy with (including
coordination of timing) the recovery mechanisms present in any
underlying server transport network (for example, Ethernet, SDH,
OTN, WDM) to avoid race conditions between the layers.</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>
<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><list counter="Requirements" style="format %d">
<t>MPLS-TP MUST support 1+1 protection.<list style="letters">
<t>MPLS-TP 1+1 support MUST include bidirectional
protection switching for P2P connectivity, and this SHOULD
be the default behavior for 1+1 protection.</t>
<t>Unidirectional 1+1 protection for P2MP connectivity
MUST be supported.</t>
<t>Unidirectional 1+1 protection for P2P connectivity is
not required.</t>
</list></t>
<t>MPLS-TP MUST support 1:n protection (including 1:1
protection).<list style="letters">
<t>MPLS-TP 1:n support MUST include bidirectional
protection switching for P2P connectivity, and this 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.</t>
<t>The action of protection switching MUST NOT cause user
data to loop. Backtracking is allowed.</t>
</list></t>
</list>Note: Support for extra traffic (as defined in <xref
target="ITU.G870.2008">G.870</xref>) is not required in
MPLS-TP.</t>
</section>
<section title="Restoration">
<t><list counter="Requirements" style="format %d">
<t>The restoration LSP MUST be able to share resources with
the LSP 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>
</list></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
restoration.</t>
<t>MPLS-TP MUST support the sharing of protection bandwidth by
allowing best effort traffic.</t>
<t>MPLS-TP MUST support the definition of shared protection
groups to allow the coordination of protection actions
resulting from triggers caused by events at different
locations in the network.</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 title="Reversion">
<t><list counter="Requirements" style="format %d">
<t>MPLS-TP protection mechanisms MUST support revertive and
non- revertive behavior. Reversion MUST be the default
behavior.</t>
<t>MPLS-TP restoration mechanisms MAY support revertive and
non- revertive behavior.</t>
</list></t>
</section>
</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 triggers.</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 of 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.</t>
<t>There MUST be support for the configuration of timers used
for recovery operation.</t>
<t>Restoration resources MAY be pre-planned and selected a
priori, or computed after failure occurrence.</t>
<t>When preemption is supported for recovery 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 support: <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)</t>
</list></t>
<t>In-band OAM MAY be used for:<list style="letters">
<t>signaling of administrative control</t>
<t>protection state coordination</t>
</list></t>
</list></t>
</section>
<section 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>
<t>Note that topology-specific recovery mechanisms are subject to
the development of requirements using the normal IETF process.</t>
<section 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 MEs 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 management plane transactions during
a maintenance operation (e.g., ring upgrade) – less than
are required by other recovery mechanisms.</t>
</list></t>
<t>It may be observed that the requirements in this section are
fully compatible with the generic requirements expressed above,
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>Recovery actions in a ring MUST be data plane functions
triggered by different elements of control. The triggers are
configured by management or control planes and are subject to
configurable policy.</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>MPLS-TP recovery in ring topologies MAY support multiple
failures without reconfiguring the protection actions.</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>MPLS-TP Recovery mechanisms applicable to a ring MUST be
equally applicable in physical and logical rings.</t>
<t>Recovery techniques in a ring SHOULD be identical to those
in general networks to simplify implementation. 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 behaviour. 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 MUST include a
mechanism to allow an implementation to handle coexisting
requests (i.e., multiple requests – not necessarily
arriving simultaneously) for protection switching based on
priority.</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>
<t>MUST support the coordination of triggers caused by events
at different locations in a ring. Note that this is the ring
equivalent of the definition of shared protection groups.</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>Prioritization of critical services.</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.draft-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>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.draft-ietf-mpls-mpls-and-gmpls-security-framework"></xref>.</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, Lou Berger, Italo
Busi, John Drake, Adrian Farrel, Eric Gray, Neil Harrison, Huub van
Helvoort, Wataru Imajuku, Julien Meuric, Tom Nadeau, Hiroshi Ohta,
George Swallow, Tomonori Takeda 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.I-D.gray-mpls-tp-nm-req.xml. -->
<reference anchor="I-D.gray-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="January" year="2009" />
<abstract></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-gray-mpls-tp-nm-req-02" />
<format target="http://www.ietf.org/internet-drafts/draft-gray-mpls-tp-nm-req-01.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.gray-mpls-tp-nm-req.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-00" />
<format target="http://www.ietf.org/internet-drafts/draft-vigoureux-mpls-tp-oam-requirements-00"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.ietf-mpls-tp-oam-requirements.xml. -->
</references>
<references title="Informative References">
<!--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. -->
<!--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.RFC.5331.xml. -->
<reference anchor="RFC5331">
<front>
<title abbrev="Upstream Label Assignment">MPLS Upstream Label
Assignment and Context-Specific Label Space</title>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization></organization>
</author>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<date month="August" year="2008" />
<abstract>
<t>RFC 3031 limits the MPLS architecture to downstream-assigned
MPLS labels. This document introduces the notion of
upstream-assigned MPLS labels. It describes the procedures for
upstream MPLS label assignment and introduces the concept of a
"Context-Specific Label Space". [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5331" />
<format octets="30779" target="ftp://ftp.isi.edu/in-notes/rfc5331.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.5331.xml. -->
<!--Begin inclusion reference.I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework.xml. -->
<reference anchor="I-D.draft-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-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-mpls-mpls-and-gmpls-security-framework-03"
type="TXT" />
</reference>
<!-- End inclusion reference.I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework.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. -->
<!--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.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.G870.2008.xml. -->
<reference anchor="ITU.G870.2008">
<front>
<title abbrev="OTN Terms">Terms and definitions for optical
transport networks (OTN)</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.870" />
</reference>
<!-- End inclusion reference.ITU.G870.2008.xml.-->
<!--Begin inclusion reference.ITU.G8080.2000.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.2000.xml.-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:53:08 |