draft-ietf-ccamp-oam-configuration-fwk-01.txt   draft-ietf-ccamp-oam-configuration-fwk-02.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: September 10, 2009 Nortel Expires: April 29, 2010 Alcatel-Lucent
J. He J. He
Huawei Huawei
March 9, 2009 October 26, 2009
OAM Configuration Framework and Requirements for GMPLS RSVP-TE OAM Configuration Framework and Requirements for GMPLS RSVP-TE
draft-ietf-ccamp-oam-configuration-fwk-01 draft-ietf-ccamp-oam-configuration-fwk-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
OAM is an integral part of transport connections, hence it is OAM is an integral part of transport connections, hence 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 while other technologies require extra configuration to establish and
and configure OAM entities. This document specifies extensions to configure OAM entities. This document specifies extensions to
RSVP-TE to support the establishment and configuration of OAM RSVP-TE to support the establishment and configuration of OAM
entities along with LSP signaling. entities along with LSP 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 document are to be interpreted as described in
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 10 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 10 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9
3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 11 3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 10
3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11
3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 13 3.4. TCME Configuration TLV . . . . . . . . . . . . . . . . . . 13
3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 13 3.5. NIME Configuration TLV . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3.6. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 3.7. OAM configuration errors . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Discussion on alternatives . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 lately Ethernet division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet
Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS
Transport Profile (MPLS-TP). In most of these technologies there are Transport Profile (MPLS-TP). In most of these technologies there are
skipping to change at page 5, line 25 skipping to change at page 4, line 25
health and performance of the connections and to trigger data plane health and performance of the connections and to trigger data plane
(DP) recovery mechanisms. Similarly to connections, OAM functions (DP) recovery mechanisms. Similarly to connections, OAM functions
follow general principles but also have some technology specific follow general principles but also have some technology specific
characteristics. characteristics.
OAM is an integral part of transport connections, hence it is OAM is an integral part of transport connections, hence 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 while other technologies require extra configuration to establish and
and configure OAM entities. In some situations the use of OAM configure OAM entities. In some situations the use of OAM functions,
functions, like those of Fault- (FM) and Performance Management like those of Fault- (FM) and Performance Management (PM), may be
(PM), may be optional confirming to actual network management optional confirming to actual network management policies. Hence the
policies. Hence the network operator must be able to choose network operator must be able to choose which kind of OAM functions
which kind of OAM functions to apply to specific connections and to apply to specific connections and with what parameters the
with what parameters the selected OAM functions should be configured selected OAM functions should be configured and operated. To achieve
and operated. To achieve this objective OAM entities and specific this objective OAM entities and specific functions must be
functions must be selectively configurable. selectively configurable.
In general, it is required that the management plane and control In general, it is required that the management plane and control
plane connection establishment mechanisms are synchronized with OAM plane connection establishment mechanisms are synchronized with OAM
establishment and activation. In particular, if the GMPLS control establishment and activation. In particular, if the GMPLS control
plane is employed it is desirable to bind OAM setup and configuration plane is employed it is desirable to bind OAM setup and configuration
to connection establishment signaling to avoid two separate to connection establishment signaling to avoid two separate
management/configuration steps (connection setup followed by OAM management/configuration steps (connection setup followed by OAM
configuration) which increases delay, processing and more importantly configuration) which increases delay, processing and more importantly
may be prune to misconfiguration errors. Once OAM entities are setup may be prune to misconfiguration errors. Once OAM entities are setup
and configured pro-active as well as on-demand OAM functions can be and configured pro-active as well as on-demand OAM functions can be
skipping to change at page 7, line 44 skipping to change at page 6, line 44
requirements, including providing additional OAM, survivability and requirements, including providing additional OAM, survivability and
other maintenance functions not currently supported by MPLS. other maintenance functions not currently supported by MPLS.
Specific OAM requirements for MPLS-TP are specified in Specific OAM requirements for MPLS-TP are specified in
[MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane
to configure and control OAM entities. to configure and control OAM entities.
o The use of OAM functions SHOULD be optional for the operator. A o The use of OAM functions SHOULD be optional for the operator. A
network operator SHOULD be able to choose which OAM functions to network operator SHOULD be able to choose which OAM functions to
use and which Maintenance Entity to apply them to. use and which Maintenance Entity to apply them to.
o The MPLS-TP control pane MUST support the configuration and o The MPLS-TP control plane MUST support the configuration and
modification of OAM maintenance points as well as the activation/ modification of OAM maintenance points as well as the activation/
deactivation of OAM when the transport path is established or deactivation of OAM when the transport path is established or
modified. OAM functions SHOULD be configurable as part of modified. OAM functions SHOULD be configurable as part of
connectivity (LSP or PW) management. connectivity (LSP or PW) management.
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-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will
support explicitly-routed Ethernet connections. CFM can be used to support explicitly-routed Ethernet connections. CFM can be used to
track the liveliness of PBB-TE connections and detect data plane track the liveliness of PBB-TE connections and detect data plane
skipping to change at page 10, line 11 skipping to change at page 9, line 11
That is generic OAM parameters and data plane or OAM technology That is generic OAM parameters and data plane or OAM technology
specific parameters must be separated. specific parameters must be separated.
3. GMPLS RSVP-TE Extensions 3. GMPLS RSVP-TE Extensions
3.1. Operation overview 3.1. Operation overview
In general, two types of Maintenance Poits (MPs) can be In general, two types of Maintenance Poits (MPs) can be
distinguished: Maintenance End Points (MEPs) and Maintenance distinguished: Maintenance End Points (MEPs) and Maintenance
Intermediate Points (MIPs). MEPs are located at the ends of an LSP Intermediate Points (MIPs). MEPs are capable of initiating and
and are capable of initiating and terminating OAM messages for Fault terminating OAM messages for Fault Management (FM) and Performance
Management (FM) and Performance Monitoring (PM). MIPs on the other Monitoring (PM). MIPs on the other hand are located at transit nodes
hand are located at transit nodes of an LSP and are capable of of an LSP and are capable of reacting to some OAM messages but
reacting to some OAM messages but otherwise do not initiate messages. otherwise do not initiate messages. Maintenance Entity (ME) refers
Maintenance Entity (ME) refers to an association of MEPs and MIPs to an association of MEPs and MIPs that are provisioned to monitor an
that are provisioned to monitor an LSP. The ME association is LSP. The ME association is achieved by configuring MPs of an ME with
achieved by configuring MPs of an ME with the same unique ME the same unique ME Assocication ID (MA ID). Each MEP must have
Assocication ID (MA ID). Each MEP must have unique identification unique identification (MEP ID) within a Maintenance Entity.
(MEP ID) within a Maintenance Entity.
When an LSP is signaled forwarding association is established between When an LSP is signaled forwarding association is established between
endpoints and transit nodes via label bindings. This association endpoints and transit nodes via label bindings. This association
creates a context for the OAM entities monitoring the LSP. On top of creates a context for the OAM entities monitoring the LSP. On top of
this association OAM entities may be configured with an MA ID and MEP this association OAM entities may be configured with an MA ID and MEP
IDs. The MA ID may be used to detect misconfiguration errors and IDs. The MA ID may be used to detect misconfiguration errors and
leaking OAM traffic. While the MEP ID can be used to demultiplex and leaking OAM traffic. While the MEP ID can be used to demultiplex and
identify the originating MEP of OAM messages. Since MIPs do not identify the originating MEP of OAM messages. Since MIPs do not
originate OAM packets, on top of the configuration of Maintenance originate OAM packets, on top of the configuration of Maintenance
Entity associations, no specific configuration is required for them. Entity associations, no specific configuration is required for them.
Along the LSP several Tandem Connections may be provisioned and
associated to the end-to-end connection. These Tandem Connections
may implement their own OAM monitoring entities. The Tandem
Connection Maintenance Entities (TCMEs) provide the same monitoring
capabilities for a segment of a connection as what is possible on an
end-to-end basis. As the endpoints of a TCME may be (and usually
are) intermediate nodes of an end-to-end LSP, the placement of TCME
ingress and egress endpoints must be explicitly identified.
Altough provisioned together with the end-to-end connection, each
TCME defines a new context for the OAM entities, which is independent
from the end-to-end connection. The MA ID and MEP IDs for a TCME are
within this new context.
When an LSP is signaled Non-Intrusive Maintenance Elements (NIME) may
be deployed along the path. These elements differ from the MIPs as
they implemetn egress MEP functions: they not only process OAM
messages but they can also trigger consequent actions, for instance,
initiate segment protection switching. The NIMEs belong to the OAM
entity context of the end-to-end LSP and, thus, the same MA ID is
applied. As the NIMEs are placed at intermediate nodes, their
placement must be explicitly indicated.
In addition to the MA and MEP identification parameters pro-active In addition to the MA and MEP identification parameters pro-active
OAM functions (e.g., Continuity Check (CC), Performance Monitoring) OAM functions (e.g., Continuity Check (CC), Performance Monitoring)
may have specific parameters requiring configuration as well. In may have specific parameters requiring configuration as well. In
particular, the frequency of periodic CC packets and the measurement particular, the frequency of periodic CC packets and the measurement
interval for loss and delay measurements may need to be configured. interval for loss and delay measurements may need to be configured.
MEP MEP
+-------------+ +-------------+
|OAM Functions| |OAM Functions|
| FM | PM | | FM | PM |
skipping to change at page 11, line 23 skipping to change at page 10, line 44
data plane technology a set of OAM solutions may be applicable. The data plane technology a set of OAM solutions may be applicable. The
OAM configuration framework allows selecting a specific OAM solution OAM configuration framework allows selecting a specific OAM solution
to be used for the signaled LSP and provides technology specific TLVs to be used for the signaled LSP and provides technology specific TLVs
to carry further detailed configuration information. to carry further detailed configuration information.
3.2. LSP Attributes flags 3.2. 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. [RFC4420] bits and hence is limited to differentiate only 8 options. [RFC4420]
defines a new object 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, [RFC4420] allows options and support new applications. Furthermore, [RFC4420] 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
options and attributes may apply only to key LSRs on the path such as options and attributes may apply only to key LSRs on the path such as
the ingress LSR and egress LSR. Options and attributes can be the ingress LSR and egress LSR. Options and attributes can be
signaled transparently, and only examined at those points that need signaled transparently, and only examined at those points that need
to act on them. The LSP_ATTRIBUTES object and the to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES
LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide objects are defined in [RFC4420] to provide means to signal LSP
means to signal LSP attributes and options in the form of TLVs. attributes and options in the form of TLVs. Options and attributes
Options and attributes signaled in the LSP_ATTRIBUTES object can be signaled in the LSP_ATTRIBUTES object can be passed transparently
passed transparently through LSRs not supporting a particular option through LSRs not supporting a particular option or attribute, while
or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined
object must be examined and processed by each LSR. One TLV is and processed by each LSR. One TLV is defined in [RFC4420]: the
defined in [RFC4420]: the Attributes Flags TLV. Attributes Flags TLV.
One bit (10 IANA to assign): "OAM MEP entities desired" is allocated One bit (10 IANA to assign): "OAM MEP entities desired" is allocated
in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" in the LSP Attributes Flags TLV. If the "OAM MEP entities desired"
bit is set it is indicating that the establishment of OAM MEP bit is set it is indicating that the establishment of OAM MEP
entities are required at the endpoints of the signaled LSP. If the entities are required at the endpoints of the signaled LSP. If the
establishment of MEPs is not supported an error must be generated: establishment of MEPs is not supported an error must be generated:
"OAM Problem/MEP establishment not supported". "OAM Problem/MEP establishment not supported".
If the "OAM MEP entities desired" bit is set and additional If the "OAM MEP entities desired" bit is set and additional
parameters are needed to configure the OAM entities an OAM parameters are needed to configure the OAM entities an OAM
skipping to change at page 12, line 40 skipping to change at page 12, line 20
| OAM Type | Reserved | OAM Function | | OAM Type | Reserved | OAM Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub-TLVs ~ ~ sub-TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (2) (IANA to Type: indicates a new type: the OAM Configuration TLV (2) (IANA to
assign). assign).
OAM Type: specifies the technology specify OAM method. If the OAM Type: specifies the technology specific OAM method. If the
requested OAM method is not supported an error must be generated: requested OAM method is not supported an error must be generated:
"OAM Problem/Unsupported OAM Type". "OAM Problem/Unsupported OAM Type".
This document defines no types. The receiving node based on the OAM This document defines no types. The receiving node based on the OAM
Type will check if a corresponding technology specific OAM Type will check if a corresponding technology specific OAM
configuration sub-TLV is included. If different technology specific configuration sub-TLV is included. If different technology specific
OAM configuration sub-TLV is included than what was specified in the OAM configuration sub-TLV is included than what was specified in the
OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch". OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch".
OAM Type Description OAM Type Description
skipping to change at page 13, line 32 skipping to change at page 13, line 11
OAM Function". OAM Function".
This document defines the following flags. This document defines the following flags.
OAM Function Flag Description OAM Function Flag Description
--------------------- --------------------------- --------------------- ---------------------------
0 Connectivity Monitoring 0 Connectivity Monitoring
1 Performance Monitoring/Loss 1 Performance Monitoring/Loss
2 Performance Monitoring/Delay 2 Performance Monitoring/Delay
3.4. Monitoring Disabled - Admin_Status bit 3.4. TCME Configuration TLV
Two TCME Configuration TLVs together specify a Tandem Connection
Monitoring entity: they designate the TCM ingress and TCM egress
MEPs, respectively. TCME Configuration TLVs are carried in
HOP_ATTRIBUTES subobjects [HOP_ATTR] in the ERO, the corresponding
node in the ERO identifies where TCME MEP is placed. Both TCME
Configuration TLVs of the same TCME must specify the same OAM
technology and method.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type |H|M| Level | OAM Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the TCME Configuration TLV (2) (IANA to
assign).
OAM Type: specifies the technology specific OAM method. The OAM Type
values defined for OAM Configuration TLV are applied here. If the
requested OAM method is not supported an error must be generated:
"OAM Problem/Unsupported OAM Type".
One bit (Flag H) is allocated to indicate which endpoint of a TCME is
encoded by the TCME Configuration TLV. Setting this flag indicates
the ingress endpoints while clearing it indicates the egress one.
One bit (Flag M) "TCME MIP entities desired" is allocated. This flag
indicates if OAM MIP entities monitoring the TCME are required. If
this function is not supported an error must be generated: "OAM
Problem/TCME MIP establishment not supported".
Level provides a key for the ingress node to determine the egress of
the same TCME. Therefore, the same Level values must be set to the
ingress and egress endpoints of the same TCME. Overlapping
(including nesting) TCM entities must use different Level values, but
two entries not having common segments may use the same Level value.
Value 0 is reserved and must not be used to identify a TCM entity.
Futher technology specific constraints of the Level value may be
defined by accompying documents.
OAM Function Flags: specifies pro-active OAM functions (e.g.,
connectivity monitoring, loss and delay measurement) that should be
established and configured. Same flags are applied as for OAM
Configuration TLV.
Both TLVs may contain technology sub-TLVs and the encoded sub-TLVs
are relevant to the referred monitoring endpoint. The TCM ingress
may update the OAM configuration of the egress point by changing
already defined sub-TLVs or by adding new sub-TLVs.
If the node, where TCME endpoint is to be configured, does not
support that feature, must generate an error: "OAM Problem/TCM not
supported".
Since a TCME Configuration TLV pair encodes a TCME, the ingress node
must check if a proper TCME Configuration TLV encoding the egress MEP
is included in the ERO. If no such TLV (i.e., the same Level value
is set and flag H is cleared) is found an error must be generated:
"OAM Problem/TCM Egress is not properly configured".
The above check ensures that a TCM egress will not be configured
without peering TCM ingress. Therefore, there is no need TCME
ingress checking procedure at the TCME egress.
3.5. NIME Configuration TLV
Inserting a NIME Configuration TLV into a HOP_ATTRIBUTES object
[HOP_ATTR] indicates that a non-intrusive monitoring element is to be
configured. Futhermore, it encodes what OAM technology and method
should be used at that entity.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type |D|U| Level | OAM Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the NIM OAM Configuration TLV (3) (IANA
to assign).
OAM Type: specifies the technology specify OAM method. If the
requested OAM method is not supported an error must be generated:
"OAM Problem/Unsupported OAM Type". The same OAM type values to be
used as for OAM Configuration TLV.
Level value indicates which OAM flow of the connection is monitored:
the end-to-end OAM flow (Level = 0) or TCM entity associated to the
connection (Level > 0).
Two bits (Flags D,U) indicates the direction of the monitored entity.
The downstream traffic is monitored if flag D is set, while setting
flag U means monitoring the upstream direction. Both directions are
monitored if both flags are set. When both flags are cleared or the
flag U is set but the LSP is not bidirectional an error must be
generated: "OAM Problem/Invalid NIM direction defined".
OAM Function Flags: specifies pro-active OAM functions (e.g.,
connectivity monitoring, loss and delay measurement) that should be
established and configured. Same procedures and flags applied as for
OAM Configuration TLV.
3.6. Monitoring Disabled - Admin_Status bit
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].
One bit is allocated for the administrative control of OAM One bit is allocated for the administrative control of OAM
monitoring. In addition to the Reflect (R) bit, 7 bits are currently monitoring. In addition to the Reflect (R) bit, 7 bits are currently
occupied (assigned by IANA or temporarily blocked by work in progress occupied (assigned by IANA or temporarily blocked by work in progress
Internet drafts). As the 24th bit (IANA to assign) this draft Internet drafts). As the 24th bit (IANA to assign) this draft
introduces the Monitoring Disabled (M) bit. When this bit is set the introduces the Monitoring Disabled (M) bit. When this bit is set the
monitoring and OAM triggered alarms of the LSP are disabled (e.g., no monitoring and OAM triggered alarms of the LSP are disabled (e.g., no
continuity check messages are sent, no AIS is generated). continuity check messages are sent, no AIS is generated).
3.5. OAM configuration errors 3.7. 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 is defined. Error Values is defined.
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 (IANA to assign): "MEP entities it must use the error value (IANA to assign): "MEP
establishment not supported" or "MIP establishment not supported" establishment not supported" or "MIP establishment not supported"
respectively in the PathErr message. respectively in the PathErr message.
skipping to change at page 15, line 5 skipping to change at page 16, line 22
with error value:"OAM Type Mismatch" in the PathErr message. with error value:"OAM Type Mismatch" in the PathErr message.
There is a hierarchy in between the OAM configuration elements. If There is a hierarchy in between the OAM configuration elements. If
this hierarchy is broken an the error value: "OAM Problem/ this hierarchy is broken an the error value: "OAM Problem/
Configuration Error" must be used in the PathErr message. Configuration Error" must be used in the PathErr message.
If a node does not support a specific OAM Function it must use the If a node does not support a specific OAM Function it must use the
error value (IANA to assign): "Unsupported OAM Function" in the error value (IANA to assign): "Unsupported OAM Function" in the
PathErr message. PathErr message.
If an intermediate node is configured as a TCM ingress node, but no
egress node for the same TCM entity is encoded in the ERO it must use
"OAM Problem/TCM Egress is not properly configured" error value in
the PathErr message
If the node, where TCME endpoint is to be configured, does not
support that feature, must generate an error: "OAM Problem/TCM not
supported".
If the technology does not support deploying MIPs monitoring a TCME
an error must be generated by the TCME ingress: "OAM Problem/TCME MIP
establishment not supported".
If an intermediate node is configured as a non-intrusive monitoring
node, but direction flags encode an invalid direction (both flags are
set to 0 or flag "U" is set in the case of an unidirectional LSP) the
node must issue a PathErr message with "OAM Problem/invalid NIM
direction defined".
4. IANA Considerations 4. IANA Considerations
One bit (Monitoring Disabled (M)) needs to be allocated in the One bit (Monitoring Disabled (M)) needs to be allocated in the
ADMIN_STATUS Object. ADMIN_STATUS Object.
One bit ("OAM entities desired") needs to be allocated in the LSP One bit ("OAM entities desired") needs to be allocated in the LSP
Attributes Flag Registry. Attributes Flag Registry.
This document specifies one new TLVs to be carried in the This document specifies one new TLVs to be carried in the
LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages:
skipping to change at page 20, line 16 skipping to change at page 22, line 16
[GELS-Framework] [GELS-Framework]
"GMPLS Ethernet Label Switching Architecture and "GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress. Framework", Internet Draft, work in progress.
[GMPLS-OAM] [GMPLS-OAM]
"OAM Requirements for Generalized Multi-Protocol Label "OAM Requirements for Generalized Multi-Protocol Label
Switching (GMPLS) Networks", Internet Draft, work in Switching (GMPLS) Networks", Internet Draft, work in
progress. progress.
[HOP_ATTR]
Kern, A. and A. Takacs, "Encoding of Attributes of LSP
hops using RSVP-TE", Internet-draft Work in progress,
October 2009.
[IEEE-CFM] [IEEE-CFM]
"IEEE 802.1ag, Draft Standard for Connectivity Fault "IEEE 802.1ag, Draft Standard for Connectivity Fault
Management", work in progress. Management", work in progress.
[IEEE-PBBTE] [IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone "IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress. Bridging Traffic Engineering", work in progress.
[MPLS-TP-FWK] [MPLS-TP-FWK]
"A Framework for MPLS in Transport Networks", Internet "A Framework for MPLS in Transport Networks", Internet
skipping to change at page 21, line 16 skipping to change at page 24, line 16
Attila Takacs Attila Takacs
Ericsson Ericsson
Laborc u. 1. Laborc u. 1.
Budapest, 1037 Budapest, 1037
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Don Fedyk Don Fedyk
Nortel Alcatel-Lucent
600 Technology Park Drive Groton, MA 01450
Billerica, MA 01821
USA USA
Email: dwfedyk@nortel.com Email: donald.fedyk@alcatel-lucent.com
Jia He Jia He
Huawei Huawei
Email: hejia@huawei.com Email: hejia@huawei.com
 End of changes. 20 change blocks. 
74 lines changed or deleted 219 lines changed or added

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