draft-ietf-ccamp-oam-configuration-fwk-11.txt   draft-ietf-ccamp-oam-configuration-fwk-12.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: June 5, 2014 Alcatel-Lucent Expires: July 16, 2014 Alcatel-Lucent
J. He J. He
Huawei Huawei
December 2, 2013 January 12, 2014
GMPLS RSVP-TE extensions for OAM Configuration GMPLS RSVP-TE extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk-11 draft-ietf-ccamp-oam-configuration-fwk-12
Abstract Abstract
Operations, Administration and Maintenance is an integral part of Operations, Administration and Maintenance is an integral part of
transport connections, hence it is required that Operations, transport connections, hence it is required that Operations,
Administration and Maintenance functions are activated/deactivated in Administration and Maintenance functions are activated/deactivated in
sync with connection commissioning/decommissioning; avoiding spurious sync with connection commissioning/decommissioning; avoiding spurious
alarms and ensuring consistent operation. In certain technologies, alarms and ensuring consistent operation. In certain technologies,
Operations, Administration and Maintenance 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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 July 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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 . . . . . . . 8
3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9
3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10
4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 10 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 11
4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 10 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 11
4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12
4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 13 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 14
4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14
4.3. Administrative Status Information . . . . . . . . . . . . 14 4.3. Administrative Status Information . . . . . . . . . . . . 15
4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15
4.5. Considerations on Point-to-Multipoint OAM Configuration . 15 4.5. Considerations on Point-to-Multipoint OAM Configuration . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 16 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17
5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 16 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17
5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 17 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18
5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 17 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18
5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 18 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19
5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 18 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19
5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 18 5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19
5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 19 5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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., 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 5, line 28 skipping to change at page 5, line 28
o From [RFC5654]: The MPLS-TP control plane MUST support the o From [RFC5654]: The MPLS-TP control plane MUST support the
configuration and modification of OAM maintenance points as well configuration and modification of OAM maintenance points as well
as the activation/ deactivation of OAM when the transport path or as the activation/ deactivation of OAM when the transport path or
transport service is established or modified. transport service is established or modified.
Ethernet Connectivity Fault Management (CFM) defines an adjunct Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet
networks support explicitly-routed Ethernet connections. CFM can be networks support explicitly-routed Ethernet connections. CFM can be
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 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 WSON, TDM
based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921] based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921]
and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, 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 the operator MUST be able to configure and control the following OAM
functions: 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
skipping to change at page 7, line 28 skipping to change at page 7, line 22
OAM identifiers, as well as the configuration of OAM functions, are OAM identifiers, as well as the configuration of OAM functions, are
technology specific (i.e., vary depending on the data plane technology specific (i.e., vary depending on the data plane
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.
Administrative Status Information is carried in the ADMIN_STATUS
Object. The Administrative Status Information is described in
[RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
[RFC3473]. Two bits are allocated for the administrative control of
OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled"
(O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms
MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled.
When the "OAM Alarms Enabled" bit is set OAM triggered alarms are
enabled and associated consequent actions MUST be executed including
the notification to the management system. When this bit is cleared,
alarms are suppressed and no action SHOULD be executed and the
management system SHOULD NOT be notified.
The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES objects are
defined in [RFC5420] to provide means to signal LSP attributes and
options in the form of TLVs. Options and attributes signaled in the
LSP_ATTRIBUTES object can be passed transparently through LSRs not
supporting a particular option or attribute, while the contents of
the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by
each LSR. One bit "OAM MEP entities desired" is allocated in the LSP
Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. If the
"OAM MEP entities desired" bit is set it is indicating that the
establishment of OAM MEP entities are required at the endpoints of
the signaled LSP. One bit "OAM MIP entities desired" is allocated in
the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or
LSP_REQUIRED_ATTRIBUES objects. If the "OAM MIP entities desired"
bit is set in the LSP_ATTRIBUTES Flags TLV in the
LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
establishment of OAM MIP entities is required at every transit node
of the signaled LSP.
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 plane enabled in the appropriate order. When using the GMPLS control plane
for both LSP establishment and to enable OAM functions on the LSPs, for both LSP establishment and to enable OAM functions on the LSPs,
the control of both processes is bound to 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
skipping to change at page 10, line 35 skipping to change at page 11, line 9
the downstream direction. In the case of a bidirectional connection, the downstream direction. In the case of a bidirectional connection,
it MUST leave in place the OAM sink functions associated to the it MUST leave in place the OAM sink functions associated to the
upstream direction. The remote end, after receiving the Path upstream direction. The remote end, after receiving the Path
message, MUST remove all associated OAM entities and functions and message, MUST remove all associated OAM entities and functions and
reply with a Resv message without an OAM Configuration TLV. The reply with a Resv message without an OAM Configuration TLV. The
initiator completely removes OAM entities and functions after the initiator completely removes OAM entities and functions after the
Resv message arrived. Resv message arrived.
4. RSVP-TE Extensions 4. RSVP-TE Extensions
RFC Editor Note: remove/update "IANA" and "IANA to assign" notes in
the document once the assignments have been made.
4.1. LSP Attributes Flags 4.1. LSP Attributes Flags
In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to
indicate options and attributes of the LSP. The Flags field has 8 indicate options and attributes of the LSP. The Flags field has 8
bits and hence is limited to differentiate only 8 options. [RFC5420] bits and hence is limited to differentiate only 8 options. [RFC5420]
defines new objects for RSVP-TE messages to allow the signaling of defines new objects for RSVP-TE messages to allow the signaling of
arbitrary attribute parameters making RSVP-TE easily extensible to arbitrary attribute parameters making RSVP-TE easily extensible to
support new applications. Furthermore, [RFC5420] allows options and support new applications. Furthermore, [RFC5420] allows options and
attributes that do not need to be acted on by all Label Switched attributes that do not need to be acted on by all Label Switched
Routers (LSRs) along the path of the LSP. In particular, these Routers (LSRs) along the path of the LSP. In particular, these
skipping to change at page 12, line 30 skipping to change at page 13, line 7
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]. Ingress and object forward unchanged as specified in [RFC5420]. Ingress and
egress nodes that support the OAM Configuration TLV but that do not egress nodes that support the OAM Configuration TLV but that do not
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".
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
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
skipping to change at page 13, line 50 skipping to change at page 14, line 32
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The Length field of the TLV. Bits are numbered from left to right. The
TLV is padded to 4-octet alignment. The Length field indicates the TLV is padded to 4-octet alignment. The Length field indicates the
size of the padded TLV in octets. IANA is requested to maintain the size of the padded TLV in octets. IANA is requested to maintain the
OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". OAM Function Flags in the new "RSVP-TE OAM Configuration Registry".
This document defines the following flags. 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
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".
skipping to change at page 15, line 36 skipping to change at page 16, line 25
messages. messages.
P2MP OAM mechanisms are very specific to the data plane technology, P2MP OAM mechanisms are very specific to the data plane technology,
therefore in this document, we only highlight the basic principles of therefore in this document, we only highlight the basic principles of
P2MP OAM configuration. We consider only the root to leaf OAM flows, P2MP OAM configuration. We consider only the root to leaf OAM flows,
and as such, aspects of the configuration of return paths are outside and as such, aspects of the configuration of return paths are outside
the scope of our discussions. We also limit our consideration to the the scope of our discussions. We also limit our consideration to the
case where all leaves must successfully establish OAM entities with case where all leaves must successfully establish OAM entities with
identical configuration in order the P2MP OAM is successfully identical configuration in order the P2MP OAM is successfully
established. In any case, the discussion set forth below provides established. In any case, the discussion set forth below provides
only guidelines for P2MP OAM configuration, details will be specified only guidelines for P2MP OAM configuration. However at minimum the
in technology specific documents. below procedures SHOULD be specified for P2MP OAM configuration in a
technology specific document.
The root node may use a single Path message or multiple Path messages The root node may use a single Path message or multiple Path messages
to setup the whole P2MP tree. In the case when multiple Path to setup the whole P2MP tree. In the case when multiple Path
messages are used, the root node is responsible to keep the OAM messages are used, the root node is responsible to keep the OAM
Configuration information consistent in each of the sent Path Configuration information consistent in each of the sent Path
messages, i.e., the same information MUST be included in all Path messages, i.e., the same information MUST be included in all Path
messages used to construct the multicast tree. Each branching node messages used to construct the multicast tree. Each branching node
will propagate the Path message downstream on each of the branches, will propagate the Path message downstream on each of the branches,
when constructing a Path message the OAM Configuration information when constructing a Path message the OAM Configuration information
MUST be copied unchanged from the received Path message, including MUST be copied unchanged from the received Path message, including
skipping to change at page 16, line 44 skipping to change at page 17, line 33
5. IANA Considerations 5. IANA Considerations
5.1. ADMIN_STATUS Object Bit Flags 5.1. ADMIN_STATUS Object Bit Flags
IANA maintains a registry called "Generalized Multi-Protocol Label IANA maintains a registry called "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Parameters" with a sub-registry called Switching (GMPLS) Signaling Parameters" with a sub-registry called
"Administrative Status Information Flags". "Administrative Status Information Flags".
IANA is requested to allocate two new flags as follows: IANA is requested to allocate two new flags as follows:
Bit Number | Hex Value | Name | Reference Bit Number | Hex Value | Name | Reference
-----------+------------+--------------------------+----------- -----------+------------+--------------------------+-----------
TBA | TBA | OAM Alarms Enabled (O) | [This.ID] TBA | TBA | OAM Alarms Enabled (O) | [This.ID]
TBA | TBA | OAM Flows Enabled (M) | [This.ID] TBA | TBA | OAM Flows Enabled (M) | [This.ID]
5.2. LSP Attributes Flags 5.2. LSP Attributes Flags
IANA maintains a registry called "Resource Reservation Protocol- IANA maintains a registry called "Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) Parameters" with a subregistry called Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
"Attribute Flags". "Attribute Flags".
IANA is requested to allocate two new flags as follows: IANA is requested to allocate two new flags as follows:
Bit | Name | Attribute | Attribute | RRO | Reference Bit | Name | Attribute | Attribute | RRO | Reference
No | | Flags Path | Flags Resv | | No | | Flags Path | Flags Resv | |
----+------------------+------------+------------+-----+---------- ----+------------------+------------+------------+-----+----------
TBA | OAM MEP | | | | TBA | OAM MEP | | | |
skipping to change at page 17, line 41 skipping to change at page 18, line 36
TBA| OAM Configuration TLV| Yes | Yes |[This.ID] TBA| OAM Configuration TLV| Yes | Yes |[This.ID]
5.4. RSVP Error Code 5.4. RSVP Error Code
IANA maintains a registry called "Resource Reservation Protocol IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Error Codes and (RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes". Globally-Defined Error Value Sub-Codes".
IANA is requested to allocate one new Error Code as follows: IANA is requested to allocate one new Error Code as follows:
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] 1 | MEP establishment not supported | [This.ID]
2 | MIP establishment not supported | [This.ID] 2 | MIP establishment not supported | [This.ID]
3 | Unsupported OAM Type | [This.ID] 3 | Unsupported OAM Type | [This.ID]
4 | Configuration Error | [This.ID] 4 | Configuration Error | [This.ID]
5 | OAM Type Mismatch | [This.ID] 5 | OAM Type Mismatch | [This.ID]
6 | Unsupported OAM Function | [This.ID] 6 | Unsupported OAM Function | [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:
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 | Not allocated |
5.5.2. OAM Sub-TLVs Sub-Registry 5.5.2. OAM Sub-TLVs Sub-Registry
skipping to change at page 18, line 48 skipping to change at page 19, line 42
"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 | Not allocated |
32-65534 | Not allocated | 32-65534 | Not allocated |
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.
IANA is requested to populate the registry as follows. IANA is requested to populate the registry as follows.
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-... | 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
for message integrity and node authentication are deployed. Since for message integrity and node authentication are deployed. Since
the OAM configuration extensions rely on the hop-by-hop exchange of the OAM configuration extensions rely on the hop-by-hop exchange of
exiting RSVP-TE messages, procedures specified for RSVP message exiting RSVP-TE messages, procedures specified for RSVP message
security in [RFC2747] can be used to mitigate possible attacks. security in [RFC2747] can be used to mitigate possible attacks.
For a more comprehensive discussion on GMPLS security, please see the For a more comprehensive discussion of GMPLS security, and attack
Security Framework for MPLS and GMPLS Networks [RFC5920]. mitigation techniques, please see the Security Framework for MPLS and
Cryptography can be used to protect against many attacks described in GMPLS Networks [RFC5920].
[RFC5920].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 21, line 45 skipping to change at page 22, line 41
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: don.fedyk@gmail.com
Jia He Jia He
Huawei Huawei
Email: hejia@huawei.com Email: hejia@huawei.com
 End of changes. 27 change blocks. 
92 lines changed or deleted 128 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/