draft-ietf-ccamp-oam-configuration-fwk-12.txt   draft-ietf-ccamp-oam-configuration-fwk-13.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: July 16, 2014 Alcatel-Lucent Expires: August 29, 2014 Hewlett-Packard Company
J. He J. He
Huawei Huawei
January 12, 2014 February 25, 2014
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-12 draft-ietf-ccamp-oam-configuration-fwk-13
Abstract Abstract
Operations, Administration and Maintenance is an integral part of Operations, Administration and Maintenance (OAM) is an integral part
transport connections, hence it is required that Operations, of transport connections, hence it is required that OAM functions are
Administration and Maintenance functions are activated/deactivated in activated/deactivated in sync with connection commissioning/
sync with connection commissioning/decommissioning; avoiding spurious decommissioning; avoiding spurious alarms and ensuring consistent
alarms and ensuring consistent operation. In certain technologies, operation. In certain technologies, OAM entities are inherently
Operations, Administration and Maintenance entities are inherently
established once the connection is set up, while other technologies established once the connection is set up, while other technologies
require extra configuration to establish and configure Operations, require extra configuration to establish and configure OAM entities.
Administration and Maintenance entities. This document specifies This document specifies extensions to RSVP-TE to support the
extensions to RSVP-TE to support the establishment and configuration establishment and configuration of OAM entities along with Label
of Operations, Administration and Maintenance entities along with Switched Path signaling.
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
skipping to change at page 2, line 4 skipping to change at page 1, line 47
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 July 16, 2014.
This Internet-Draft will expire on August 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 46
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17
5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17
5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18
5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18
5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19
5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19
5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19 5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19
5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20 5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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., Dense
division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider Wavelength Division Multiplexing (DWDM)), time-division multiplexing
Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most (e.g., SONET/SDH, G.709), and Ethernet Provider Backbone Bridging -
of these technologies, there are Operations, Administration and Traffic Engineering (PBB-TE) and MPLS. In most of these
Maintenance (OAM) functions employed to monitor the health and technologies, there are Operations, Administration and Maintenance
performance of the connections and to trigger data plane (DP) (OAM) functions employed to monitor the health and performance of the
recovery mechanisms. Similar to connection provisioning, OAM connections and to trigger data plane (DP) recovery mechanisms.
functions follow general principles, but also have some technology Similar to connection provisioning, OAM functions follow general
specific characteristics. principles, but also have some technology specific characteristics.
OAM is an integral part of transport connections. Therefore it is OAM is an integral part of transport connections. Therefore it is
required that OAM functions are activated/deactivated in sync with required that OAM functions are activated/deactivated in sync with
connection commissioning/decommissioning; avoiding spurious alarms connection commissioning/decommissioning; avoiding spurious alarms
and ensuring consistent operation. In certain technologies, OAM and ensuring consistent operation. In certain technologies, OAM
entities are inherently established once the connection is set up, entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and while other technologies require extra configuration to establish and
configure OAM entities. In some situations the use of OAM functions, configure OAM entities. In some situations the use of OAM functions,
such as Fault Management (FM) and Performance Management (PM), may be such as Fault Management (FM) and Performance Management (PM), may be
optional (based on network management policies). Hence, the network optional (based on network management policies). Hence, the network
skipping to change at page 3, line 50 skipping to change at page 3, line 50
OAM configuration) which increases delay, processing, and more OAM configuration) which increases delay, processing, and more
importantly may be prone to misconfiguration errors. Once OAM importantly may be prone to misconfiguration errors. Once OAM
entities are setup and configured, pro-active as well as on-demand entities are setup and configured, pro-active as well as on-demand
OAM functions can be activated via the management plane. On the OAM functions can be activated via the management plane. On the
other hand, it should be possible to activate/deactivate pro-active other hand, it should be possible to activate/deactivate pro-active
OAM functions via the GMPLS control plane as well. In some OAM functions via the GMPLS control plane as well. In some
situations it may be possible to use the GMPLS control plane to situations it may be possible to use the GMPLS control plane to
control on-demand OAM functions too. control on-demand OAM functions too.
This document describes requirements for OAM configuration and This document describes requirements for OAM configuration and
control via RSVP-TE. Extensions to the RSVP-TE protocol are control via Resource Reservation Protocol - Traffic Engineering
specified providing a framework to configure and control OAM entities (RSVP-TE). Extensions to the RSVP-TE protocol are specified
along with the capability to carry technology specific information. providing a framework to configure and control OAM entities along
with the capability to carry technology specific information.
Extensions can be grouped into: generic elements that are applicable Extensions can be grouped into: generic elements that are applicable
to any OAM solution; and technology specific elements that provide to any OAM solution; and technology specific elements that provide
additional configuration parameters, which may only be needed for a additional configuration parameters, which may only be needed for a
specific OAM technology. This document specifies the technology specific OAM technology. This document specifies the technology
agnostic elements and specifies the way additional technology agnostic elements and specifies the way additional technology
specific OAM parameters are provided. specific OAM parameters are provided.
This document addresses end-to-end OAM configuration, that is, the This document addresses end-to-end OAM configuration, that is, the
setup of OAM entities bound to an end-to-end LSP, and configuration setup of OAM entities bound to an end-to-end Label-Switched Path
and control of OAM functions running end-to-end in the LSP. (LSP), and configuration and control of OAM functions running end-to-
Configuration of OAM entities for LSP segments and tandem connections end in the LSP. Configuration of OAM entities for LSP segments and
are out of the scope of this document. tandem connections are out of the scope of this document.
The mechanisms described in this document provide an additional The mechanisms described in this document provide an additional
option for bootstrapping OAM that is not intended to replace or option for bootstrapping OAM that is not intended to replace or
deprecate the use of other technology specific OAM bootstrapping deprecate the use of other technology specific OAM bootstrapping
techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The
procedures specified in this document are intended only for use in procedures specified in this document are intended only for use in
environments where RSVP-TE signaling is used to set up the LSPs that environments where RSVP-TE signaling is used to set up the LSPs that
are to be monitored using OAM. are to be monitored using OAM.
2. Requirements 2. Requirements
skipping to change at page 5, line 37 skipping to change at page 5, line 38
used to track the liveliness of PBB-TE connections and detect data used to track the liveliness of PBB-TE connections and detect data
plane failures. In the IETF, the GMPLS controlled Ethernet Label plane failures. In the IETF, the GMPLS controlled Ethernet Label
Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the
GMPLS control plane to support the establishment of PBB-TE data plane GMPLS control plane to support the establishment of PBB-TE data plane
connections. Without control plane support separate management connections. Without control plane support separate management
commands would be needed to configure and start CFM. commands would be needed to configure and start CFM.
GMPLS based OAM configuration and control needs to provide a general GMPLS based OAM configuration and control needs to provide a general
framework to be applicable to a wide range of data plane technologies framework to be applicable to a wide range of data plane technologies
and OAM solutions. There are three typical data plane technologies and OAM solutions. There are three typical data plane technologies
used for transport applications: wavelength based such as WSON, TDM used for transport applications: wavelength based such as Wavelength
based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921] Switched Optical Networks (WSON), Time-Division Multiplexing (TDM)
and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, based such as Synchronous Digital Hierarchy (SDH) and Synchronous
the operator MUST be able to configure and control the following OAM Optical Networking (SONET), and packet based such as MPLS-TP
functions: [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data
planes, the operator MUST be able to configure and control the
following OAM functions:
o It MUST be possible to explicitly request the setup of OAM o It MUST be possible to explicitly request the setup of OAM
entities for the signaled LSP and provide specific information for entities for the signaled LSP and provide specific information for
the setup if this is required by the technology. the setup if this is required by the technology.
o Control of alarms is important to avoid false alarm indications o Control of alarms is important to avoid false alarm indications
and reporting to the management system. It MUST be possible to and reporting to the management system. It MUST be possible to
enable/disable alarms generated by OAM functions. In some cases, enable/disable alarms generated by OAM functions. In some cases,
selective alarm control may be desirable when, for instance, the selective alarm control may be desirable when, for instance, the
operator is only concerned about critical alarms. Therefore the operator is only concerned about critical alarms. Therefore the
skipping to change at page 8, line 32 skipping to change at page 8, line 34
bidirectional connections, in addition to the OAM source function, bidirectional connections, in addition to the OAM source function,
the initiator node MUST set up the OAM sink function and prepare it the initiator node MUST set up the OAM sink function and prepare it
to receive OAM messages. During this time the OAM alarms MUST be to receive OAM messages. During this time the OAM alarms MUST be
suppressed (e.g., due to missing or unidentified OAM messages). To suppressed (e.g., due to missing or unidentified OAM messages). To
achieve OAM alarm suppression, Path message MUST be sent with the achieve OAM alarm suppression, Path message MUST be sent with the
"OAM Alarms Enabled" ADMIN_STATUS flag cleared. "OAM Alarms Enabled" ADMIN_STATUS flag cleared.
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 message SHOULD be sent and neither the OAM entities nor the LSP
established. If OAM entities are established successfully, the OAM SHOULD be established. If OAM entities are established successfully,
sink function MUST be prepared to receive OAM messages, but MUST NOT the OAM sink function MUST be prepared to receive OAM messages, but
generate any OAM alarms (e.g., due to missing or unidentified OAM MUST NOT generate any OAM alarms (e.g., due to missing or
messages). In the case of bidirectional connections, in addition to unidentified OAM messages). In the case of bidirectional
the OAM sink function, an OAM source function MUST be set up and, connections, in addition to the OAM sink function, an OAM source
according to the requested configuration, the OAM source function function MUST be set up and, according to the requested
MUST start sending OAM messages. Then a Resv message MUST be sent configuration, the OAM source function MUST start sending OAM
back, including the LSP_Attributes Flags TLV, with the appropriate messages. Then a Resv message MUST be sent back, including the
setting of the "OAM MEP entities desired" and "OAM MIP entities LSP_Attributes Flags TLV, with the appropriate setting of the "OAM
desired" flags, and the OAM Configuration TLV that corresponds to the MEP entities desired" and "OAM MIP entities desired" flags, and the
established and configured OAM entities and functions. Depending on OAM Configuration TLV that corresponds to the established and
the OAM technology, some elements of the OAM Configuration TLV MAY be configured OAM entities and functions. Depending on the OAM
updated/changed; i.e., if the remote end is not supporting a certain technology, some elements of the OAM Configuration TLV MAY be updated
OAM configuration it may suggest an alternative setting, which may or /changed; i.e., if the remote end is not supporting a certain OAM
may not be accepted by the initiator of the Path message. If it is configuration it may suggest an alternative setting, which may or 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 message MAY be sent tearing down
Details of this operation are technology specific and should be the LSP. Details of this operation are technology specific and
described in accompanying technology specific documents. should be described in accompanying technology specific documents.
When the initiating side receives the Resv message, it completes any When the initiating side receives the Resv message, it completes any
pending OAM configuration and enables the OAM source function to send pending OAM configuration and enables the OAM source function to send
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
skipping to change at page 13, line 14 skipping to change at page 13, line 22
support a specific OAM Type MUST respond with an error indicating support a specific OAM Type MUST respond with an error indicating
"OAM Problem/Unsupported OAM Type". "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".
Length: indicates the total length of the TLV in octets. The TLV
MUST be zero-padded so that the TLV is four octet aligned.
Two groups of TLVs are defined: generic sub-TLVs and technology Two groups of TLVs are defined: generic sub-TLVs and technology
specific sub-TLVs. Generic sub-TLVs carry information that are specific sub-TLVs. Generic sub-TLVs carry information that are
applicable independent of the actual OAM technology, while technology applicable independent of the actual OAM technology, while technology
specific sub-TLVs are providing configuration parameters for specific specific sub-TLVs are providing configuration parameters for specific
OAM technologies. This document defines one generic sub-TLV, see OAM technologies. This document defines one generic sub-TLV, see
Section 4.2.1, while it is foreseen that technology specific sub-TLVs Section 4.2.1, while it is foreseen that technology specific sub-TLVs
will be defined by separate documents. 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
skipping to change at page 15, line 8 skipping to change at page 15, line 11
If technology-specific configuration information is needed for a If technology-specific configuration information is needed for a
specific "OAM Type", then this information is carried in a specific "OAM Type", then this information is carried in a
technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM
Configuration TLV MUST NOT contain more than one technology- specific Configuration TLV MUST NOT contain more than one technology- specific
sub-TLV. IANA is requested to maintain the OAM technology specific sub-TLV. IANA is requested to maintain the OAM technology specific
sub-TLV space in 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, which is specified for RSVP-TE in [RFC3473]. The
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in Administrative Status Information is described in [RFC3471].
[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 monitoring. Two bits (IANA to assign) are allocated by this
document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O)
bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST
be enabled; if it is cleared, OAM mechanisms MUST be disabled. When be enabled; if it is cleared, OAM mechanisms MUST be disabled. When
the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled
and associated consequent actions MUST be executed including the and associated consequent actions MUST be executed including the
notification to the management system. When this bit is cleared, notification to the management system. When this bit is cleared,
alarms are suppressed and no action SHOULD be executed and the alarms are suppressed and no action SHOULD be executed and the
skipping to change at page 18, line 45 skipping to change at page 19, line 5
Error Code | Meaning | Reference Error Code | Meaning | Reference
-----------+-------------+------------- -----------+-------------+-------------
TBA | OAM Problem | [This.ID] TBA | OAM Problem | [This.ID]
The value is to be selected from the range 0-239. The value is to be selected from the range 0-239.
The following Error Value sub-codes are defined for this new Error The following Error Value sub-codes are defined for this new Error
Code as follows: Code as follows:
Value | Description | Reference Value | Description | Reference
------+---------------------------------+-------------- --------+---------------------------------+--------------
1 | MEP establishment not supported | [This.ID] 0 | Reserved | [This.ID]
2 | MIP establishment not supported | [This.ID] 1 | MEP establishment not supported | [This.ID]
3 | Unsupported OAM Type | [This.ID] 2 | MIP establishment not supported | [This.ID]
4 | Configuration Error | [This.ID] 3 | Unsupported OAM Type | [This.ID]
5 | OAM Type Mismatch | [This.ID] 4 | Configuration Error | [This.ID]
6 | Unsupported OAM Function | [This.ID] 5 | OAM Type Mismatch | [This.ID]
6 | Unsupported OAM Function | [This.ID]
7-32767 | Unassigned |
32768-65535| Reserved for Private Use | [This.ID]
5.5. RSVP-TE OAM Configuration Registry 5.5. RSVP-TE OAM Configuration Registry
IANA is requested to create a new registry called "RSVP-TE OAM IANA is requested to create a new registry called "RSVP-TE OAM
Configuration Registry". Configuration Registry".
IANA is requested to create sub-registries as defined in the IANA is requested to create sub-registries as defined in the
following subsections: following subsections. The registration procedures specified are as
defined in [RFC5226].
5.5.1. OAM Types Sub-Registry 5.5.1. OAM Types Sub-Registry
IANA is requested to create the "OAM Types" sub-registry of the IANA is requested to create the "OAM Types" sub-registry of the
"RSVP-TE OAM Configuration Registry" as follows: "RSVP-TE OAM Configuration Registry" as follows:
Range | Registration Procedures Range | Registration Procedures
-------+------------------------- -------+-------------------------
0-255 | IETF Review 0-255 | IETF Review
There are no initial values in this registry. IANA should show the There are no initial values in this registry. IANA should show the
registry as follows: registry as follows:
OAM Type Number | OAM Type Description | Reference OAM Type Number | OAM Type Description | Reference
----------------+----------------------+-------------- ----------------+----------------------+--------------
0-255 | Not allocated | 0-255 | Unassigned |
5.5.2. OAM Sub-TLVs Sub-Registry 5.5.2. OAM Sub-TLVs Sub-Registry
IANA is requested to create the "OAM Sub-TLVs" sub-registry of the IANA is requested to create the "OAM Sub-TLVs" sub-registry of the
"RSVP-TE OAM Configuration Registry" as follows: "RSVP-TE OAM Configuration Registry" as follows:
Range | Purpose | Registration Procedures Range | Purpose | Registration Procedures
------------+------------------------------|------------------------ ------------+------------------------------|------------------------
0-31 | Generic Sub-TLVs | IETF Review 0-31 | Generic Sub-TLVs | IETF Review
32-65534 | Technology-specific Sub-TLVs | IETF Review 32-65534 | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs | Experimental 65535-65536 | Experimental Sub-TLVs | Experimental
IANA is requested to populate the registry as follows: IANA is requested to populate the registry as follows:
Sub-TLV Type | Description | Reference Sub-TLV Type | Description | Reference
-------------+----------------------------+------- -------------+----------------------------+-------
0 | Reserved | [This.ID] 0 | Reserved | [This.ID]
1 | OAM Function Flags Sub-TLV | [This.ID] 1 | OAM Function Flags Sub-TLV | [This.ID]
2-31 | Not allocated | 2-31 | Unassigned |
32-65534 | Not allocated | 32-65534 | Unassigned |
5.5.3. OAM Function Flags Sub-Registry 5.5.3. OAM Function Flags Sub-Registry
IANA is requested to create the "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". sub-registry of the "RSVP-TE OAM Configuration Registry".
New values in the registry are allocated by "IETF Review". There is 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 no top value to the range. Bits are counted from bit 0 as the first
bit transmitted. bit transmitted.
skipping to change at page 20, line 26 skipping to change at page 20, line 41
OAM Function Flag | Description OAM Function Flag | Description
bit number | bit number |
------------------+--------------------------------------------- ------------------+---------------------------------------------
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)
6-... | Not allocated 6-... | Unassigned
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 21, line 20 skipping to change at page 21, line 33
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
8.2. Informative References 8.2. Informative References
[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
skipping to change at page 22, line 35 skipping to change at page 23, line 4
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 Hewlett-Packard Company
Groton, MA 01450 153 Taylor Street
Littleton, MA 01460
USA USA
Email: don.fedyk@gmail.com Email: don.fedyk@hp.com
Jia He Jia He
Huawei Huawei
Email: hejia@huawei.com Email: hejia@huawei.com
 End of changes. 24 change blocks. 
77 lines changed or deleted 89 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/