draft-ietf-ccamp-oam-configuration-fwk-10.txt   draft-ietf-ccamp-oam-configuration-fwk-11.txt 
Network Working Group A. Takacs Network Working Group A. Takacs
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track D. Fedyk Intended status: Standards Track D. Fedyk
Expires: December 17, 2013 Alcatel-Lucent Expires: June 5, 2014 Alcatel-Lucent
J. He J. He
Huawei Huawei
June 15, 2013 December 2, 2013
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-10 draft-ietf-ccamp-oam-configuration-fwk-11
Abstract Abstract
OAM is an integral part of transport connections, hence it is Operations, Administration and Maintenance is an integral part of
required that OAM functions are activated/deactivated in sync with transport connections, hence it is required that Operations,
connection commissioning/decommissioning; avoiding spurious alarms Administration and Maintenance functions are activated/deactivated in
and ensuring consistent operation. In certain technologies, OAM sync with connection commissioning/decommissioning; avoiding spurious
entities are inherently established once the connection is set up, alarms and ensuring consistent operation. In certain technologies,
while other technologies require extra configuration to establish and Operations, Administration and Maintenance entities are inherently
configure OAM entities. This document specifies extensions to established once the connection is set up, while other technologies
RSVP-TE to support the establishment and configuration of OAM require extra configuration to establish and configure Operations,
entities along with LSP signaling. Administration and Maintenance entities. This document specifies
extensions to RSVP-TE to support the establishment and configuration
of Operations, Administration and Maintenance entities along with
Label Switched Path signaling.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2014.
This Internet-Draft will expire on December 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 19 skipping to change at page 2, line 23
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6
3.1. Establishment of OAM Entities and Functions . . . . . . . 7 3.1. Establishment of OAM Entities and Functions . . . . . . . 7
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 10
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 10
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 13
4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14
4.3. Administrative Status Information . . . . . . . . . . . . 13 4.3. Administrative Status Information . . . . . . . . . . . . 14
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14
4.5. Considerations on Point-to-Multipoint OAM Configuration . 14 4.5. Considerations on Point-to-Multipoint OAM Configuration . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 18
5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 18
5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
GMPLS is designed as an out-of-band control plane supporting dynamic GMPLS is designed as an out-of-band control plane supporting dynamic
connection provisioning for any suitable data plane technology; connection provisioning for any suitable data plane technology;
including spatial switching (e.g., incoming port or fiber to outgoing including spatial switching (e.g., incoming port or fiber to outgoing
port or fiber), wavelength-division multiplexing (e.g., DWDM), time- port or fiber), wavelength-division multiplexing (e.g., DWDM), time-
division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider
Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most
of these technologies, there are Operations, Administration and of these technologies, there are Operations, Administration and
skipping to change at page 6, line 31 skipping to change at page 6, line 36
parameters for the LSP. parameters for the LSP.
o The extensions MUST allow the operator to use only a minimal set o The extensions MUST allow the operator to use only a minimal set
of OAM configuration and control features if supported by the OAM of OAM configuration and control features if supported by the OAM
solution or network management policy. Generic OAM parameters and solution or network management policy. Generic OAM parameters and
data plane or OAM technology specific parameters MUST be data plane or OAM technology specific parameters MUST be
supported. supported.
3. RSVP-TE based OAM Configuration 3. RSVP-TE based OAM Configuration
In general, two types of Maintenance Points (MPs) can be In general, two types of maintenance points can be distinguished:
distinguished: Maintenance End Points (MEPs) and Maintenance Maintenance Entity Group End Points (MEPs) and Maintenance Entity
Intermediate Points (MIPs). MEPs reside at the ends of an LSP and Group Intermediate Points (MIPs). MEPs reside at the ends of an LSP
are capable of initiating and terminating OAM messages for Fault and are capable of initiating and terminating OAM messages for Fault
Management (FM) and Performance Monitoring (PM). MIPs on the other Management (FM) and Performance Monitoring (PM). MIPs on the other
hand, are located at transit nodes of an LSP and are capable of hand, are located at transit nodes of an LSP and are capable of
reacting to some OAM messages but otherwise do not initiate messages. reacting to some OAM messages but otherwise do not initiate messages.
Maintenance Entity (ME) refers to an association of MEPs and MIPs Maintenance Entity (ME) refers to an association of MEPs and MIPs
that are provisioned to monitor an LSP. The ME association is that are provisioned to monitor an LSP.
achieved by configuring MPs to belong to the same ME.
When an LSP is signaled, a forwarding association is established When an LSP is signaled, a forwarding association is established
between endpoints and transit nodes via label bindings. This between endpoints and transit nodes via label bindings. This
association creates a context for the OAM entities monitoring the association creates a context for the OAM entities monitoring the
LSP. On top of this association, OAM entities may be configured to LSP. On top of this association, OAM entities may be configured to
unambiguously identify MPs and MEs. unambiguously identify MEs.
In addition to MP and ME identification parameters, pro-active OAM In addition to ME identification parameters, pro-active OAM functions
functions (e.g., Continuity Check (CC) and Performance Monitoring (e.g., Continuity Check (CC) and Performance Monitoring (PM)) may
(PM)) may have additional parameters that require configuration as have additional parameters that require configuration as well. In
well. In particular, the frequency of periodic CC packets and the particular, the frequency of periodic CC packets and the measurement
measurement interval for loss and delay measurements may need to be interval for loss and delay measurements may need to be configured.
configured.
The above parameters may be either derived from LSP provisioning The above parameters may be either derived from LSP provisioning
information, or alternatively, pre-configured default values can be information, or alternatively, pre-configured default values can be
used. In the simplest case, the control plane MAY provide used. In the simplest case, the control plane MAY provide
information on whether or not OAM entities need to be setup for the information on whether or not OAM entities need to be setup for the
signaled LSP. If OAM entities are created, control plane signaling signaled LSP. If OAM entities are created, control plane signaling
MUST also provide a means to activate/deactivate OAM message flows MUST also provide a means to activate/deactivate OAM message flows
and associated alarms. and associated alarms.
OAM identifiers, as well as the configuration of OAM functions, are OAM identifiers, as well as the configuration of OAM functions, are
skipping to change at page 7, line 28 skipping to change at page 7, line 31
technology and the chosen OAM solution). In addition, for any given technology and the chosen OAM solution). In addition, for any given
data plane technology, a set of OAM solutions may be applicable. data plane technology, a set of OAM solutions may be applicable.
Therefore, the OAM configuration framework allows selecting a Therefore, the OAM configuration framework allows selecting a
specific OAM solution to be used for the signaled LSP and provides specific OAM solution to be used for the signaled LSP and provides
means to carry detailed OAM configuration information in technology means to carry detailed OAM configuration information in technology
specific TLVs. specific TLVs.
3.1. Establishment of OAM Entities and Functions 3.1. Establishment of OAM Entities and Functions
In order to avoid spurious alarms, OAM functions should be setup and In order to avoid spurious alarms, OAM functions should be setup and
enabled in the appropriate order. When using the GMPLS control enabled in the appropriate order. When using the GMPLS control plane
plane, establishment and enabling of OAM functions MUST be bound to for both LSP establishment and to enable OAM functions on the LSPs,
RSVP-TE message exchanges. the control of both processes is bound to RSVP-TE message exchanges.
An LSP may be signaled and established without OAM configuration An LSP may be signaled and established without OAM configuration
first, and OAM entities may be added later with a subsequent re- first, and OAM entities may be added later with a subsequent re-
signaling of the LSP. Alternatively, the LSP may be setup with OAM signaling of the LSP. Alternatively, the LSP may be setup with OAM
entities with the first signaling of the LSP. The below procedures entities with the first signaling of the LSP. The below procedures
apply to both cases. apply to both cases.
Before initiating a Path message with OAM Configuration information, Before initiating a Path message with OAM Configuration information,
an initiating node MUST establish and configure the corresponding OAM an initiating node MUST establish and configure the corresponding OAM
entities locally. But until the LSP is established, OAM source entities locally. But until the LSP is established, OAM source
skipping to change at page 8, line 11 skipping to change at page 8, line 15
When the Path message arrives at the receiver, the remote end MUST When the Path message arrives at the receiver, the remote end MUST
establish and configure OAM entities according to the OAM information establish and configure OAM entities according to the OAM information
provided in the Path message. If this is not possible, a PathErr provided in the Path message. If this is not possible, a PathErr
SHOULD be sent and neither the OAM entities nor the LSP SHOULD be SHOULD be sent and neither the OAM entities nor the LSP SHOULD be
established. If OAM entities are established successfully, the OAM established. If OAM entities are established successfully, the OAM
sink function MUST be prepared to receive OAM messages, but MUST NOT sink function MUST be prepared to receive OAM messages, but MUST NOT
generate any OAM alarms (e.g., due to missing or unidentified OAM generate any OAM alarms (e.g., due to missing or unidentified OAM
messages). In the case of bidirectional connections, in addition to messages). In the case of bidirectional connections, in addition to
the OAM sink function, an OAM source function MUST be set up and, the OAM sink function, an OAM source function MUST be set up and,
according to the requested configuration, the OAM source function according to the requested configuration, the OAM source function
MUST start sending OAM messages. Then a Resv message is sent back, MUST start sending OAM messages. Then a Resv message MUST be sent
including the OAM Configuration TLV that corresponds to the back, including the LSP_Attributes Flags TLV, with the appropriate
setting of the "OAM MEP entities desired" and "OAM MIP entities
desired" flags, and the OAM Configuration TLV that corresponds to the
established and configured OAM entities and functions. Depending on established and configured OAM entities and functions. Depending on
the OAM technology, some elements of the OAM Configuration TLV MAY be the OAM technology, some elements of the OAM Configuration TLV MAY be
updated/changed; i.e., if the remote end is not supporting a certain updated/changed; i.e., if the remote end is not supporting a certain
OAM configuration it may suggest an alternative setting, which may or OAM configuration it may suggest an alternative setting, which may or
may not be accepted by the initiator of the Path message. If it is may not be accepted by the initiator of the Path message. If it is
accepted, the initiator will reconfigure its OAM functions according accepted, the initiator will reconfigure its OAM functions according
to the information received in the Resv message. If the alternate to the information received in the Resv message. If the alternate
setting is not acceptable a ResvErr may be sent tearing down the LSP. setting is not acceptable a ResvErr may be sent tearing down the LSP.
Details of this operation are technology specific and should be Details of this operation are technology specific and should be
described in accompanying technology specific documents. described in accompanying technology specific documents.
skipping to change at page 8, line 36 skipping to change at page 8, line 42
OAM messages. OAM messages.
After this exchange, OAM entities are established and configured for After this exchange, OAM entities are established and configured for
the LSP and OAM messages are exchanged. OAM alarms can now be the LSP and OAM messages are exchanged. OAM alarms can now be
enabled. The initiator, during the period when OAM alarms are enabled. The initiator, during the period when OAM alarms are
disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS
flag set. The receiving node enables the OAM alarms after processing flag set. The receiving node enables the OAM alarms after processing
the Path message. The initiator enables OAM alarms after it receives the Path message. The initiator enables OAM alarms after it receives
the Resv message. Data plane OAM is now fully functional. the Resv message. Data plane OAM is now fully functional.
In case an egress LSR does not support the extensions defined in this
document, according to [RFC5420], it will silently ignore the new LSP
Attributes Flags as well as the TLVs carrying additional OAM
configuration information, and therefore no error will be raised that
would notify the ingress LSR about the missing OAM configuration
actions on the egress side. However, as described above, an egress
LSR conformant to the specification of this document will set the LSP
Attributes Flags and include the OAM Configuration TLV in the Resv
message indicating the configuration of the OAM mechanisms, therefore
an ingress LSR by detecting the missing information in the Resv
message will be able to recognize that the remote end does not
support the OAM configuration functionality and therefore it SHOULD
tear down the LSP, and if appropriate, signal the LSP without any OAM
configuration information.
3.2. Adjustment of OAM Parameters 3.2. Adjustment of OAM Parameters
There may be a need to change the parameters of an already There may be a need to change the parameters of an already
established and configured OAM function during the lifetime of the established and configured OAM function during the lifetime of the
LSP. To do so the LSP needs to be re-signaled with the updated LSP. To do so the LSP needs to be re-signaled with the updated
parameters. OAM parameters influence the content and timing of OAM parameters. OAM parameters influence the content and timing of OAM
messages and identify the way OAM defects and alarms are derived and messages and identify the way OAM defects and alarms are derived and
generated. Hence, to avoid spurious alarms, it is important that generated. Hence, to avoid spurious alarms, it is important that
both sides, OAM sink and source, are updated in a synchronized way. both sides, OAM sink and source, are updated in a synchronized way.
First, the alarms of the OAM sink function should be suppressed and First, the alarms of the OAM sink function should be suppressed and
skipping to change at page 9, line 25 skipping to change at page 9, line 45
negotiation phase, in the case of adjusting already configured OAM negotiation phase, in the case of adjusting already configured OAM
functions, the receiving side SHOULD NOT update the parameters functions, the receiving side SHOULD NOT update the parameters
requested in the Path message to an extent that would provide lower requested in the Path message to an extent that would provide lower
performance (e.g., lower frequency of monitoring packets) than what performance (e.g., lower frequency of monitoring packets) than what
has been in operation previously. has been in operation previously.
The initiator MUST only update its OAM sink and source functions The initiator MUST only update its OAM sink and source functions
after it received the Resv message. After this Path/Resv message after it received the Resv message. After this Path/Resv message
exchange (in both unidirectional and bidirectional LSP cases) the OAM exchange (in both unidirectional and bidirectional LSP cases) the OAM
parameters are updated and OAM is running according the new parameter parameters are updated and OAM is running according the new parameter
settings. However, OAM alarms are still disabled. A subsequent settings. However, OAM alarms are still disabled. A subsequent Path
Path/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS /Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag
flag set is needed to enable OAM alarms again. set is needed to enable OAM alarms again.
3.3. Deleting OAM Entities 3.3. Deleting OAM Entities
In some cases it may be useful to remove some or all OAM entities and In some cases it may be useful to remove some or all OAM entities and
functions from an LSP without actually tearing down the connection. functions from an LSP without actually tearing down the connection.
To avoid any spurious alarms, first the LSP MUST be re-signaled with To avoid any spurious alarms, first the LSP MUST be re-signaled with
"OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM
configuration. Subsequently, the LSP is re-signaled with "OAM MEP configuration. Subsequently, the LSP is re-signaled with "OAM MEP
Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags
cleared, and without the OAM Configuration TLV, this MUST result in cleared, and without the OAM Configuration TLV, this MUST result in
the deletion of all OAM entities associated with the LSP. All the deletion of all OAM entities associated with the LSP. All
control and data plane resources in use by the OAM entities and control and data plane resources in use by the OAM entities and
skipping to change at page 10, line 50 skipping to change at page 11, line 23
of the signaled LSP. If the establishment of MEPs is not supported of the signaled LSP. If the establishment of MEPs is not supported
an error MUST be generated: "OAM Problem/MEP establishment not an error MUST be generated: "OAM Problem/MEP establishment not
supported". supported".
If the "OAM MEP entities desired" bit is set and additional If the "OAM MEP entities desired" bit is set and additional
parameters need to be configured, an OAM Configuration TLV MAY be parameters need to be configured, an OAM Configuration TLV MAY be
included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
One bit (IANA to assign): "OAM MIP entities desired" is allocated in One bit (IANA to assign): "OAM MIP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the LSP_REQUIRED_ATTRIBUES objects. If the "OAM MEP entities desired"
"OAM MEP entities desired" bit is set. If the "OAM MIP entities bit is not set then this bit MUST NOT be set. If the "OAM MIP
desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the entities desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the
LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
establishment of OAM MIP entities is required at every transit node establishment of OAM MIP entities is required at every transit node
of the signaled LSP. If the establishment of a MIP is not supported of the signaled LSP. If the establishment of a MIP is not supported
an error MUST be generated: "OAM Problem/MIP establishment not an error MUST be generated: "OAM Problem/MIP establishment not
supported". supported". If an intermediate LSR does not support the extensions
defined in this document it will not recognize the "OAM MIP entities
desired" flag and although the LSP_REQUIRED_ATTRIBUTES object was
used it will not configure MIP entities and will not raise any
errors. If LSRs that are not supporting this document are to be
assumed in the network, the ingress LSR SHOULD collect per-hop
information about the LSP Attributes utilizing the LSP Attributes
sub-object of the Record Route Object as defined in [RFC5420]. When
the Record Route object is received the ingress SHOULD check whether
all intermediate LSRs set the "OAM MIP entities desired" flag
indicating support of the function, if not, depending on operator
policy the LSP MAY need to be torn down.
4.2. OAM Configuration TLV 4.2. OAM Configuration TLV
This TLV provides information about which OAM technology/method This TLV provides information about which OAM technology/method
should be used and carries sub-TLVs for any additional OAM should be used and carries sub-TLVs for any additional OAM
configuration information. The OAM Configuration TLV MAY be carried configuration information. One OAM Configuration TLV MAY be carried
in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and
Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object,
it is indicating that intermediate nodes MUST recognize and react on it is indicating that intermediate nodes MUST recognize and react on
the OAM configuration information. the OAM configuration information.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (IANA) | Length | | Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved | | OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3) (IANA to Type: indicates a new type: the OAM Configuration TLV (IANA to
assign). assign).
OAM Type: specifies the technology specific OAM method. When carried OAM Type: specifies the technology specific OAM method. When carried
in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is
not supported at any given node an error MUST be generated: "OAM not supported at any given node an error MUST be generated: "OAM
Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES
Object, intermediate nodes not supporting the OAM Type pass the Object, intermediate nodes not supporting the OAM Type pass the
object forward unchanged as specified in [RFC5420], and only Label object forward unchanged as specified in [RFC5420]. Ingress and
Edge Nodes MUST generate an error if the OAM Type is not supported at egress nodes that support the OAM Configuration TLV but that do not
the LSP end-point. support a specific OAM Type MUST respond with an error indicating
"OAM Problem/Unsupported OAM Type".
OAM Type Description OAM Type Description
------------ -------------------- ------------ --------------------
0-255 Reserved 0-255 Reserved
This document defines no types. IANA is requested to maintain the This document defines no types. IANA is requested to maintain the
values in a new "RSVP-TE OAM Configuration Registry". values in a new "RSVP-TE OAM Configuration Registry".
Two groups of TLVs are defined: generic sub-TLVs and technology
specific sub-TLVs. Generic sub-TLVs carry information that are
applicable independent of the actual OAM technology, while technology
specific sub-TLVs are providing configuration parameters for specific
OAM technologies. This document defines one generic sub-TLV, see
Section 4.2.1, while it is foreseen that technology specific sub-TLVs
will be defined by separate documents.
The receiving node, based on the OAM Type, will check if a The receiving node, based on the OAM Type, will check if a
corresponding technology specific OAM configuration sub-TLV is corresponding technology specific OAM configuration sub-TLV is
included in the OAM Configuration TLV. If the included technology included in the OAM Configuration TLV. If the included technology
specific OAM configuration sub-TLV is different from what is specific OAM configuration sub-TLV is different from what is
specified in the OAM Type an error MUST be generated: "OAM Problem/ specified in the OAM Type an error MUST be generated: "OAM Problem/
OAM Type Mismatch". IANA is requested to maintain the sub-TLV space OAM Type Mismatch". IANA is requested to maintain the sub-TLV space
in the new "RSVP-TE OAM Configuration Registry". in the new "RSVP-TE OAM Configuration Registry".
Sub-TLV Type Description Sub-TLV Type Description
------------ ------------------------------------ ------------ ------------------------------------
0 Reserved 0 Reserved
1 OAM Function Flags Sub-TLV 1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs 2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs 32- Reserved for technology specific Sub-TLVs
Note that there is a hierarchical dependency between the OAM Note that there is a hierarchical dependency between the OAM
configuration elements. First, the "OAM MEP entities desired" flag configuration elements. First, the "OAM MEP entities desired" flag
needs to be set. Only when that flag is set MAY an "OAM needs to be set. Only when that flag is set MAY an "OAM
Configuration TLV" be included in the LSP_ATTRIBUTES or Configuration TLV" be included in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on
the "OAM Type" field, it MAY carry a technology specific OAM the "OAM Type" field, it MAY carry a technology specific OAM
configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP
entities desired" flag is not set but an OAM Configuration TLV is entities desired" flag is not set but an OAM Configuration TLV is
present) an error MUST be generated: "OAM Problem/Configuration present) an error MUST be generated: "OAM Problem/Configuration
Error". Error".
4.2.1. OAM Function Flags Sub-TLV 4.2.1. OAM Function Flags Sub-TLV
As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be The "OAM Configuration TLV" MUST always include a single instance of
included in the "OAM Configuration TLV". "OAM Function Flags" the "OAM Function Flags Sub-TLV" and it MUST always be the first sub-
specifies which pro-active OAM functions (e.g., connectivity TLV. "OAM Function Flags" specifies which pro-active OAM functions
monitoring, loss and delay measurement) and which fault management (e.g., connectivity monitoring, loss and delay measurement) and which
signals MUST be established and configured. If the selected OAM fault management signals MUST be established and configured. If the
Function(s) is(are) not supported, an error MUST be generated: "OAM selected OAM Function(s) is(are) not supported, an error MUST be
Problem/Unsupported OAM Function". generated: "OAM Problem/Unsupported OAM Function".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) (IANA) | Length | | Type (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ OAM Function Flags ~ ~ OAM Function Flags ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is bitmap with extensible length based on the OAM Function Flags is bitmap with extensible length based on the
Length field of the TLV. Bits are numbered from left to right. IANA Length field of the TLV. Bits are numbered from left to right. The
is requested to maintain the OAM Function Flags in the new "RSVP-TE TLV is padded to 4-octet alignment. The Length field indicates the
OAM Configuration Registry". This document defines the following size of the padded TLV in octets. IANA is requested to maintain the
flags. OAM Function Flags in the new "RSVP-TE OAM Configuration Registry".
This document defines the following flags.
OAM Function Flag bit# Description OAM Function Flag bit# Description
--------------------- --------------------------- --------------------- ---------------------------
0 Continuity Check (CC) 0 Continuity Check (CC)
1 Connectivity Verification (CV) 1 Connectivity Verification (CV)
2 Fault Management Signal (FMS) 2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss) 3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay) 4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement 5 Performance Monitoring/Throughput Measurement
(PM/Throughput) (PM/Throughput)
4.2.2. Technology Specific Sub-TLVs 4.2.2. Technology Specific Sub-TLVs
One technology specific sub-TLV MAY be defined for each "OAM Type". If technology-specific configuration information is needed for a
This sub-TLV MUST contain any further OAM configuration information specific "OAM Type", then this information is carried in a
for that specific "OAM Type". The technology specific sub-TLV, when technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM
used, MUST be carried within the OAM Configuration TLV. IANA is Configuration TLV MUST NOT contain more than one technology- specific
requested to maintain the OAM technology specific sub-TLV space in sub-TLV. IANA is requested to maintain the OAM technology specific
the new "RSVP-TE OAM Configuration Registry". sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
4.3. Administrative Status Information 4.3. Administrative Status Information
Administrative Status Information is carried in the ADMIN_STATUS Administrative Status Information is carried in the ADMIN_STATUS
Object. The Administrative Status Information is described in Object. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473]. [RFC3473].
Two bits are allocated for the administrative control of OAM Two bits are allocated for the administrative control of OAM
monitoring. Two bits (IANA to assign) are allocated by this draft: monitoring. Two bits (IANA to assign) are allocated by this
the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O)
the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST
cleared, no OAM packets are emitted. When the "OAM Alarms Enabled" be enabled; if it is cleared, OAM mechanisms MUST be disabled. When
bit is set OAM triggered alarms are enabled and associated consequent the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled
actions are executed including the notification to the management and associated consequent actions MUST be executed including the
system. When this bit is cleared, alarms are suppressed and no notification to the management system. When this bit is cleared,
action is executed and the management system is not notified. alarms are suppressed and no action SHOULD be executed and the
management system SHOULD NOT be notified. For a detailed description
of the use of these flags see Section 3.
4.4. Handling OAM Configuration Errors 4.4. Handling OAM Configuration Errors
To handle OAM configuration errors, a new Error Code (IANA to assign) To handle OAM configuration errors, a new Error Code (IANA to assign)
"OAM Problem" is introduced. To refer to specific problems, a set of "OAM Problem" is introduced. To refer to specific problems, a set of
Error Values are defined under the "OAM Problem" error code. Error Values are defined under the "OAM Problem" error code.
If a node does not support the establishment of OAM MEP or MIP If a node does not support the establishment of OAM MEP or MIP
entities it MUST use the error value: "MEP establishment not entities it MUST use the error value: "MEP establishment not
supported" or "MIP establishment not supported" respectively in the supported" or "MIP establishment not supported" respectively in the
skipping to change at page 16, line 7 skipping to change at page 16, line 36
message flow can be enabled. Such action could be to setup two message flow can be enabled. Such action could be to setup two
independent P2MP LSPs. One LSP with OAM Configuration information independent P2MP LSPs. One LSP with OAM Configuration information
towards leaves which could successfully setup the OAM function. This towards leaves which could successfully setup the OAM function. This
can be done by pruning the leaves which failed to setup OAM of the can be done by pruning the leaves which failed to setup OAM of the
previously signaled P2MP LSP. The other P2MP LSP could be previously signaled P2MP LSP. The other P2MP LSP could be
constructed for leaves without OAM entities. The exact procedures constructed for leaves without OAM entities. The exact procedures
will be described in technology specific documents. will be described in technology specific documents.
5. IANA Considerations 5. IANA Considerations
Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 5.1. ADMIN_STATUS Object Bit Flags
to be allocated in the ADMIN_STATUS Object.
Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") IANA maintains a registry called "Generalized Multi-Protocol Label
needs to be allocated in the LSP Attributes Flags Registry. Switching (GMPLS) Signaling Parameters" with a sub-registry called
"Administrative Status Information Flags".
This document specifies one new TLV to be carried in the IANA is requested to allocate two new flags as follows:
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
messages: OAM Configuration TLV.
One new Error Code: "OAM Problem" and a set of new values: "MEP Bit Number | Hex Value | Name | Reference
establishment not supported", "MIP establishment not supported", -----------+------------+--------------------------+-----------
"Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch" TBA | TBA | OAM Alarms Enabled (O) | [This.ID]
and "Unsupported OAM Function" needs to be assigned. TBA | TBA | OAM Flows Enabled (M) | [This.ID]
IANA is requested to open a new registry: "RSVP-TE OAM Configuration 5.2. LSP Attributes Flags
Registry" that maintains the "OAM Type" code points, an associated IANA maintains a registry called "Resource Reservation Protocol-
sub-TLV space, and the allocations of "OAM Function Flags" within the Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
OAM Configuration TLV. "Attribute Flags".
RSVP-TE OAM Configuration Registry IANA is requested to allocate two new flags as follows:
OAM Type Description Bit | Name | Attribute | Attribute | RRO | Reference
------------ ------------------ No | | Flags Path | Flags Resv | |
0-255 Reserved ----+------------------+------------+------------+-----+----------
TBA | OAM MEP | | | |
| entities desired | Yes | Yes | Yes | [This.ID]
| | | | |
TBA | OAM MIP | | | |
| entities desired | Yes | Yes | Yes | [This.ID]
Sub-TLV Type Description 5.3. New LSP Attributes
------------ ------------------------------------
0 Reserved
1 OAM Function Flags Sub-TLV
2-31 Reserved for generic Sub-TLVs
32- Reserved for technology specific Sub-TLVs
OAM Function Flag bit# Description IANA maintains a registry called "Resource Reservation Protocol-
---------------------- ------------------------------- Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
0 Continuity Check (CC) "Attributes TLV Space"
1 Connectivity Verification (CV)
2 Fault Management Signal (FMS) IANA is requested to allocate one new TLV type as follows:
3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay) Type| Name |Allowed on |Allowed on |Reference
5 Performance Monitoring/Throughput Measurement | |LSP_ATTRIBUTES|LSP_REQUIRED_|
(PM/Throughput) | | |ATTRIBUTES |
6- Reserved ----+----------------------+--------------+-------------+---------
TBA| OAM Configuration TLV| Yes | Yes |[This.ID]
5.4. RSVP Error Code
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes".
IANA is requested to allocate one new Error Code as follows:
Error Code | Meaning | Reference
-----------+-------------+-------------
TBA | OAM Problem | [This.ID]
The value is to be selected from the range 0-239.
The following Error Value sub-codes are defined for this new Error
Code as follows:
Value | Description | Reference
------+---------------------------------+--------------
1 | MEP establishment not supported | [This.ID]
2 | MIP establishment not supported | [This.ID]
3 | Unsupported OAM Type | [This.ID]
4 | Configuration Error | [This.ID]
5 | OAM Type Mismatch | [This.ID]
6 | Unsupported OAM Function | [This.ID]
5.5. RSVP-TE OAM Configuration Registry
IANA is requested to create a new registry called "RSVP-TE OAM
Configuration Registry".
IANA is requested to create sub-registries as defined in the
following subsections:
5.5.1. OAM Types Sub-Registry
IANA is requested to create the "OAM Types" sub-registry of the
"RSVP-TE OAM Configuration Registry" as follows:
Range | Registration Procedures
-------+-------------------------
0-255 | IETF Review
There are no initial values in this registry. IANA should show the
registry as follows:
OAM Type Number | OAM Type Description | Reference
----------------+----------------------+--------------
0-255 | Not allocated |
5.5.2. OAM Sub-TLVs Sub-Registry
IANA is requested to create the "OAM Sub-TLVs" sub-registry of the
"RSVP-TE OAM Configuration Registry" as follows:
Range | Purpose | Registration Procedures
------------+------------------------------|------------------------
0-31 | Generic Sub-TLVs | IETF Review
32-65534 | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs | Experimental
IANA is requested to populate the registry as follows:
Sub-TLV Type | Description | Reference
-------------+----------------------------+-------
0 | Reserved | [This.ID]
1 | OAM Function Flags Sub-TLV | [This.ID]
2-31 | Not allocated |
32-65534 | Not allocated |
5.5.3. OAM Function Flags Sub-Registry
IANA is requested to create the "OAM Function Flags Sub-Registry"
sub-registry of the "RSVP-TE OAM Configuration Registry".
New values in the registry are allocated by "IETF Review". There is
no top value to the range. Bits are counted from bit 0 as the first
bit transmitted.
IANA is requested to populate the registry as follows.
OAM Function Flag | Description
bit number |
------------------+---------------------------------------------
0 | Continuity Check (CC)
1 | Connectivity Verification (CV)
2 | Fault Management Signal (FMS)
3 | Performance Monitoring/Loss (PM/Loss)
4 | Performance Monitoring/Delay (PM/Delay)
5 | Performance Monitoring/Throughput Measurement
| (PM/Throughput)
6-... | Not allocated
6. Security Considerations 6. Security Considerations
The signaling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities based on RSVP-TE messages adds a new establishment of OAM entities based on RSVP-TE messages adds a new
aspect to the security considerations discussed in [RFC3473]. In aspect to the security considerations discussed in [RFC3473]. In
particular, a network element could be overloaded, if a remote particular, a network element could be overloaded, if a remote
attacker could request liveliness monitoring, with frequent periodic attacker could request liveliness monitoring, with frequent periodic
messages, for a high number of LSPs, targeting a single network messages, for a high number of LSPs, targeting a single network
element. Such an attack can efficiently be prevented when mechanisms element. Such an attack can efficiently be prevented when mechanisms
skipping to change at page 18, line 17 skipping to change at page 20, line 40
[IEEE.802.1Q-2011] [IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2011. Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks", for Multi-Protocol Label Switched (MPLS) Networks", RFC
RFC 4377, February 2006. 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
Multiprotocol Label Switching (GMPLS) Ethernet Label Multiprotocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework", RFC 5828, Switching Architecture and Framework", RFC 5828, March
March 2010. 2010.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks", RFC
RFC 5921, July 2010. 5921, July 2010.
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control "Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering of Ethernet Provider Backbone Traffic Engineering (PBB-
(PBB-TE)", RFC 6060, March 2011. TE)", RFC 6060, March 2011.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest, 1097 Budapest 1097
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
Groton, MA 01450 Groton, MA 01450
USA USA
Email: donald.fedyk@alcatel-lucent.com Email: donald.fedyk@alcatel-lucent.com
 End of changes. 44 change blocks. 
154 lines changed or deleted 294 lines changed or added

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