GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) ConfigurationEricssonKonyves Kalman krt. 11.Budapest1097Hungaryattila.takacs@ericsson.comHewlett-Packard Company153 Taylor Street Littleton01460MAUSAdon.fedyk@hp.comHuaweiPR Chinahejia@huawei.comMPLS-TPTransport ProfileGELSEthernet Label SwitchingPBB-TEconnectivity monitoringOAM configurationOperations, Administration, and Maintenance (OAM) is an
integral part of transport connections; hence, it is required
that OAM functions be activated/deactivated in sync with
connection commissioning/decommissioning, in order to avoid spurious
alarms and ensure consistent operation. In certain technologies,
OAM entities are inherently established once the connection is
set up, while other technologies require extra configuration to
establish and configure OAM entities. This document specifies
extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) to support
the establishment and configuration of OAM entities along with
Label Switched Path signaling.GMPLS is designed as an out-of-band control plane supporting
dynamic connection provisioning for any suitable data-plane
technology, including spatial switching (e.g., incoming port or
fiber to outgoing port or fiber); wavelength-division
multiplexing (e.g., Dense Wavelength Division Multiplexing
(DWDM)); time-division multiplexing (e.g., Synchronous Optical
Networking and Synchronous Digital Hierarchy (SONET/SDH), G.709);
and Ethernet Provider Backbone Bridging - Traffic Engineering
(PBB-TE) and MPLS. In most of these technologies, there are
Operations, Administration, and Maintenance (OAM) functions
employed to monitor the health and performance of the
connections and to trigger data plane (DP) recovery
mechanisms. Similar to connection provisioning, OAM functions
follow general principles but also have some technology-specific
characteristics.OAM is an integral part of transport connections. Therefore, it is
required that OAM functions be activated/deactivated in sync with
connection commissioning/decommissioning, in order to avoid spurious
alarms and ensure consistent operation. In certain technologies, OAM
entities are inherently established once the connection is set up,
while other technologies require extra configuration to establish and
configure OAM entities. In some situations, the use of OAM functions,
such as Fault Management (FM) and Performance Management (PM), may be
optional (based on network management policies). Hence, the
network operator must be able to choose which set of OAM functions
to apply to specific connections and which parameters should be
configured and activated. To achieve this objective, OAM entities
and specific functions must be selectively configurable.In general, it is required that the management-plane and
control-plane connection establishment mechanisms be
synchronized with OAM establishment and activation. In
particular, if the GMPLS control plane is employed, it is
desirable to bind OAM setup and configuration to connection
establishment signaling to avoid two separate
management/configuration steps (connection setup followed by OAM
configuration), as these separate steps increase delay and
processing time; more importantly, they may be prone to
misconfiguration errors. Once OAM entities are set up and configured,
proactive as well as on-demand OAM functions can be activated via
the management plane. On the other hand, it should be possible to
activate/deactivate proactive OAM functions via the GMPLS
control plane as well. In some situations, it may be possible to
use the GMPLS control plane to control on-demand OAM functions
too.This document describes requirements for OAM configuration
and control via Resource Reservation Protocol - Traffic
Engineering (RSVP-TE). Extensions to the RSVP-TE protocol are
specified, 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 to any OAM solution and technology-specific
elements that provide additional configuration parameters that
may only be needed for a specific OAM technology. This document
specifies the technology-agnostic elements and specifies the way
that additional technology-specific OAM parameters are provided.This document addresses end-to-end OAM configuration, that
is, the setup of OAM entities bound to an end-to-end
Label Switched Path (LSP), and configuration and control of OAM
functions running end-to-end in the LSP. Configuration of OAM
entities for LSP segments and tandem connections is outside the
scope of this document.The mechanisms described in this document provide an additional
option for bootstrapping OAM that is not intended to replace or
deprecate the use of other technology-specific OAM bootstrapping
techniques, e.g., LSP ping for MPLS networks.
The procedures specified in this document are intended only for use in
environments where RSVP-TE signaling is used to set up the LSPs that are
to be monitored using OAM.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .This section summarizes various technology-specific OAM requirements
that can be used as a basis for an OAM configuration framework.MPLS OAM requirements are described in ,
which provides requirements to create consistent OAM functionality for
MPLS networks. The following list is an excerpt of MPLS OAM requirements
documented in that bear direct relevance to
the discussion set forth in this document:It is desired that the automation of LSP defect detection be
supported.
It is especially important in cases where large numbers of LSPs
might be tested.In particular, some LSPs may require automated
testing functionality from the ingress LSR (Label Switching Router)
to the egress LSR, while others may not.Mechanisms are required to coordinate network responses to
defects. Such mechanisms may include alarm suppression, translating
defect signals at technology boundaries, and synchronizing defect
detection times by setting appropriately bounded detection time
frames.The MPLS Transport Profile (MPLS-TP) defines a profile of MPLS
targeted at transport applications .
This profile specifies the specific MPLS characteristics
and extensions required to meet transport requirements,
including providing additional OAM, survivability, and other maintenance
functions not currently supported by MPLS. Specific OAM requirements for
MPLS-TP are specified in and . MPLS-TP poses the following requirements on the
control plane to configure and control OAM entities:From : OAM functions MUST operate and be
configurable even in the absence of a control plane. Conversely, it
SHOULD be possible to configure as well as enable/disable the
capability to operate OAM functions as part of connectivity
management, and it SHOULD also be possible to configure as well as
enable/disable the capability to operate OAM functions after
connectivity has been established.From : The MPLS-TP control plane MUST
support the configuration and modification of OAM maintenance points
as well as the activation/deactivation of OAM when the transport
path or transport service is established or modified.Ethernet Connectivity Fault Management (CFM) defines an adjunct
OAM flow that monitors connectivity in order to check the liveliness
of Ethernet networks . With PBB-TE , Ethernet networks support explicitly routed
Ethernet connections. CFM can be used to track the liveliness of PBB-TE
connections and detect data-plane failures. In the IETF, the GMPLS
Ethernet Label Switching (GELS) (see
and ) work extended the GMPLS control plane to
support the establishment of PBB-TE data-plane connections. Without
control-plane support, separate management commands would be needed to
configure and start CFM.GMPLS-based OAM configuration and control need to provide a
general framework to be applicable to a wide range of data-plane
technologies and OAM solutions. There are three typical data-plane
technologies used for transport applications: wavelength
based, such as Wavelength Switched Optical Networks (WSON);
Time-Division Multiplexing (TDM) based, such as Synchronous
Digital Hierarchy (SDH) and Synchronous Optical Networking
(SONET); and packet based, such as MPLS-TP and Ethernet PBB-TE . For all these data planes, the
operator MUST be able to configure and control the following OAM
functions:It MUST be possible to explicitly request the setup of OAM
entities for the signaled LSP and provide specific information for
the setup if this is required by the technology.Control of alarms is important to avoid false alarm indications
and reporting to the management system. It MUST be possible to
enable/disable alarms generated by OAM functions. In some cases,
selective alarm control may be desirable when, for instance, the
operator is only concerned about critical alarms. Therefore, alarms
that do not affect service should be inhibited.When periodic messages are used for liveliness checks
(Continuity Checks (CCs)) of LSPs, it MUST be possible to set the
frequency of messages. This allows proper configuration for
fulfilling the requirements of the service and/or
meeting the detection time boundaries posed by
possible congruent connectivity-check operations
of higher-layer applications. For a network operator to be able to
balance the trade-off between fast failure detection and data
overhead, it is beneficial to configure the frequency of
CC messages on a per-LSP basis.Proactive Performance Monitoring (PM) functions are used to
continuously collect information about specific characteristics of
the connection. For consistent measurement of Service Level
Agreements (SLAs), it MUST be possible to set common configuration
parameters for the LSP.The extensions MUST allow the operator to use only a
minimal set of OAM configuration and control features if
supported by the OAM solution or network management
policy. Generic OAM parameters, as well as parameters specific to
data-plane technology or OAM technology, MUST be supported.In general, two types of maintenance points can be
distinguished: Maintenance Entity Group End Points (MEPs) and
Maintenance Entity Group Intermediate Points (MIPs). MEPs reside
at the ends of an LSP and are capable of initiating and
terminating OAM messages for Fault Management (FM) and
Performance Monitoring (PM). MIPs, on the other hand, are located
at transit nodes of an LSP and are capable of reacting to some
OAM messages but otherwise do not initiate messages. "Maintenance
Entity" (ME) refers to an association of MEPs and MIPs that are
provisioned to monitor an LSP.When an LSP is signaled, a forwarding association is
established between endpoints and transit nodes via label
bindings. This association creates a context for the OAM
entities monitoring the LSP. On top of this association, OAM
entities may be configured to unambiguously identify MEs.In addition to ME identification parameters, proactive OAM
functions (e.g., CC and PM) may have additional parameters that require
configuration as well. In particular, the frequency of periodic
CC packets, and the measurement interval for loss and delay
measurements, may need to be configured.The above parameters may be derived from information related to
LSP provisioning; alternatively, pre-configured default values can be
used. In the simplest case, the control plane MAY provide
information on whether or not OAM entities need to be set up
for the signaled LSP. If OAM entities are created, control-plane
signaling MUST also provide a means to activate/deactivate
OAM message flows and associated alarms.OAM identifiers, as well as the configuration of OAM functions, are
technology specific (i.e., they vary, depending on the data-plane
technology and the chosen OAM solution). In addition, for any given
data-plane technology, a set of OAM solutions may be applicable.
Therefore, the OAM configuration framework allows selecting a
specific OAM solution to be used for the signaled LSP and
provides means to carry detailed OAM configuration information in
technology-specific TLVs. Administrative Status Information is carried in the
Admin_Status object. Administrative Status Information is
described in , and the Admin_Status
object is specified for RSVP-TE in .
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 LSP_REQUIRED_ATTRIBUTES objects
are defined in 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. The "OAM
MEP entities desired" bit is allocated in the Attribute Flags
TLV to be used in the LSP_ATTRIBUTES object.
If the "OAM MEP entities desired" bit is set, it indicates that the
establishment of OAM MEP entities is required at the endpoints
of the signaled LSP. The "OAM MIP entities desired" bit is
allocated in the Attribute Flags TLV to be used in the
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM
MIP entities desired" bit is set in the Attribute Flags TLV
in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the
establishment of OAM MIP entities is required at every transit
node of the signaled LSP.In order to avoid spurious alarms, OAM functions should be
set up and enabled in the appropriate order. When using the
GMPLS control plane for both LSP establishment and enabling
OAM functions on the LSPs, the control of both processes is
bound to RSVP-TE message exchanges.An LSP may be signaled and established without OAM
configuration first, and OAM entities may be added later with
a subsequent re-signaling of the LSP. Alternatively, the LSP
may be set up with OAM entities with the first signaling of the
LSP. The procedures below apply to both cases.Before initiating a Path message with OAM configuration
information, an initiating node MUST establish and configure
the corresponding OAM entities locally. But until the LSP is
established, OAM source functions MUST NOT start sending any
OAM messages. In the case of bidirectional connections, in
addition to the OAM source function, 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 suppressed
(e.g., due to missing or unidentified OAM messages). To
achieve OAM alarm suppression, Path messages MUST be sent with
the "OAM Alarms Enabled" Admin_Status flag cleared.When the Path message arrives at the receiver, the remote
end MUST establish and configure OAM entities according to the
OAM information provided in the Path message. If this is not
possible, a PathErr message SHOULD be sent, and neither the OAM
entities nor the LSP SHOULD be established. If OAM entities
are established successfully, the OAM sink function MUST be
prepared to receive OAM messages but MUST NOT generate any
OAM alarms (e.g., due to missing or unidentified OAM
messages). In the case of bidirectional connections, in
addition to the OAM sink function, an OAM source function MUST
be set up and, according to the requested configuration, the
OAM source function MUST start sending OAM messages. A Resv
message MUST then be sent back, including the Attribute Flags TLV,
with the appropriate setting of the "OAM MEP entities desired"
and "OAM MIP entities desired" flags, and the
OAM Configuration TLV that corresponds to the established and
configured OAM entities and functions. Depending on the OAM
technology, some elements of the OAM Configuration TLV MAY be
updated/changed, i.e., if the remote end does not support a
certain OAM configuration it may suggest an alternative
setting, which may or may not be accepted by the initiator of
the Path message. If it is accepted, the initiator will
reconfigure its OAM functions according to the information
received in the Resv message. If the alternate setting is not
acceptable, a ResvErr message MAY be sent, tearing down the LSP.
Details of this operation are technology specific and should
be described in accompanying technology-specific documents.When the initiating side receives the Resv message, it
completes any pending OAM configuration and enables the OAM
source function to send OAM messages.After this exchange, OAM entities are established and
configured for the LSP, and OAM messages are exchanged. OAM
alarms can now be enabled. During the period when OAM alarms
are disabled, the initiator sends a Path message with the "OAM
Alarms Enabled" Admin_Status flag set. The receiving node
enables OAM alarms after processing the Path message. The
initiator enables OAM alarms after it receives the Resv
message. Data-plane OAM is now fully functional.If an egress LSR does not support the extensions
defined in this document, according to , it will silently ignore the new LSP
attribute flags as well as the TLVs carrying additional OAM
configuration information, and therefore no error will be
raised that would notify the ingress LSR about the missing OAM
configuration actions on the egress side. However, as
described above, an egress LSR conformant to the specification
of this document will set the LSP attribute flags and include
the OAM Configuration TLV in the Resv message indicating the
configuration of the OAM mechanisms; therefore, by detecting
the missing information in the Resv message, an ingress LSR will
be able to recognize that the remote end does not support the
OAM configuration functionality, and therefore it SHOULD tear
down the LSP and, if appropriate, signal the LSP without any
OAM configuration information.There may be a need to change the parameters of an
already-established and configured OAM function during the lifetime
of the LSP. To do so, the LSP needs to be re-signaled with the
updated parameters. OAM parameters influence the content and
timing of OAM messages and also identify the way that OAM defects
and alarms are derived and generated. Hence, to avoid spurious
alarms, it is important that both sides -- OAM sink and source --
are updated in a synchronized way. First, the alarms of the
OAM sink function should be suppressed and only then should
expected OAM parameters be adjusted. Subsequently, the
parameters of the OAM source function can be updated. Finally,
the alarms of the OAM sink side can be enabled again.In accordance with the above operation, the LSP MUST first
be re-signaled with the "OAM Alarms Enabled" Admin_Status flag
cleared, including the updated OAM Configuration TLV
corresponding to the new parameter settings. The initiator
MUST keep its OAM sink and source functions running
unmodified, but it MUST suppress OAM alarms after the updated
Path message is sent. The receiver MUST first disable all OAM
alarms and then update the OAM parameters according to the
information in the Path message and reply with a Resv message
acknowledging the changes by including the OAM Configuration
TLV. Note that the receiving side can adjust the requested OAM
configuration parameters and reply with an updated OAM Configuration
TLV in the Resv message, reflecting the values that are actually
configured. However, in order to avoid an extensive negotiation
phase, in the case of adjusting already-configured OAM functions,
the receiving side SHOULD NOT update the parameters requested in
the Path message to an extent that would provide lower
performance (e.g., lower frequency of monitoring packets) than
what had previously been in place.The initiator MUST only update its OAM sink and source functions
after it receives the Resv message. After this Path/Resv message
exchange (in both unidirectional and bidirectional LSP cases), the OAM
parameters are updated, and OAM is running according to the new
parameter settings. However, OAM alarms are still disabled. A
subsequent Path/Resv message exchange with the "OAM Alarms Enabled"
Admin_Status flag set is needed to enable OAM alarms again.In some cases, it may be useful to remove some or all OAM
entities and functions from an LSP without actually tearing
down the connection.To avoid any spurious alarms, first the LSP MUST be
re-signaled with the "OAM Alarms Enabled" Admin_Status flag
cleared but with OAM configuration unchanged. Subsequently, the LSP
is re-signaled with "OAM MEP entities desired" and "OAM MIP
entities desired" LSP attribute flags cleared, and without
the OAM Configuration TLV, this MUST result in the deletion of
all OAM entities associated with the LSP. All control-plane and
data-plane resources in use by the OAM entities and functions
SHOULD be freed up. Alternatively, if only some OAM functions
need to be removed, the LSP is re-signaled with the updated
OAM Configuration TLV. Changes between the contents of the
previously signaled OAM Configuration TLV and the currently
received TLV represent which functions MUST be
removed/added.OAM source functions MUST be deleted first, and only after
the "OAM Alarms Disabled" can the associated OAM sink
functions be removed; this will ensure that OAM messages do
not leak outside the LSP. To this end, the initiator, before
sending the Path message, MUST remove the OAM source, hence
terminating the OAM message flow associated to the downstream
direction. In the case of a bidirectional connection, it MUST
leave in place the OAM sink functions associated to the
upstream direction. The remote end, after receiving the Path
message, MUST remove all associated OAM entities and functions
and reply with a Resv message without an OAM Configuration
TLV. The initiator completely removes OAM entities and
functions after the Resv message arrives.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 bits and hence is limited to differentiate
only 8 options. defines new objects
for RSVP-TE messages to allow the signaling of arbitrary
attribute parameters, making RSVP-TE easily extensible to
support new applications. Furthermore, allows options and attributes that do not
need to be acted on by all Label Switching 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 the
ingress LSR and egress LSR. Options and attributes can be
signaled transparently and only examined at those points that
need to act on them. The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES
objects are defined in 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 TLV is defined
in : the Attribute Flags TLV.One bit (bit number 10): "OAM MEP entities desired" is allocated
in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES
object. If the "OAM MEP entities desired" bit is set, it indicates
that the establishment of OAM MEP entities is required at the
endpoints of the signaled LSP. If the establishment of MEPs is not
supported, an error MUST be generated: "OAM Problem/MEP establishment
not supported".If the "OAM MEP entities desired" bit is set and additional
parameters need to be configured, an OAM Configuration TLV MAY be
included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.One bit (bit number 11): "OAM MIP entities desired" is
allocated in the Attribute Flags TLV to be used in the
LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM
MEP entities desired" bit is not set, then this bit MUST NOT be
set. If the "OAM MIP entities desired" bit is set in the
Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES
object, it indicates that the establishment of OAM MIP
entities is required at every transit node of the signaled
LSP. If the establishment of a MIP is not supported, an error
MUST be generated: "OAM Problem/MIP establishment not
supported". If an intermediate LSR does not support the
extensions defined in this document, it will not recognize the
"OAM MIP entities desired" flag and, although the
LSP_REQUIRED_ATTRIBUTES object was used, it will not configure
MIP entities and will not raise any errors. If LSRs that do not
support the extensions defined in this document are to be assumed
as present in the network, the ingress LSR SHOULD collect per-hop
information about the LSP attributes utilizing the LSP Attributes
sub-object of the Record Route object (RRO) as defined in . When the Record Route object is received,
the ingress SHOULD check whether all intermediate LSRs set the
"OAM MIP entities desired" flag indicating support of the
function; if not, depending on operator policy, the LSP MAY
need to be torn down. This TLV provides information about which OAM technology/method
should be used and carries sub-TLVs for any additional OAM
configuration information. One OAM Configuration TLV MAY be carried in
the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv
messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, it
indicates that intermediate nodes MUST recognize and react
on the OAM configuration information.Type: indicates a new type: the OAM Configuration TLV (3).OAM Type: specifies the technology-specific OAM
method. When carried in the LSP_REQUIRED_ATTRIBUTES object, if
the requested OAM method is not supported at any given node an
error MUST be generated: "OAM Problem/Unsupported OAM Type".
When carried in the LSP_ATTRIBUTES object, intermediate nodes
not supporting the OAM Type pass the object forward unchanged
as specified in . Ingress and egress
nodes that support the OAM Configuration TLV but that do not
support a specific OAM Type MUST respond with an error
indicating "OAM Problem/Unsupported OAM Type".This document defines no types. IANA maintains the
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 4-octet
aligned. Two groups of TLVs are defined: generic sub-TLVs and
technology-specific sub-TLVs. Generic sub-TLVs carry
information that is applicable independent of the actual OAM
technology, while technology-specific sub-TLVs are providing
configuration parameters for specific OAM technologies. This
document defines one generic sub-TLV
(see ), while
it is foreseen that technology-specific sub-TLVs will be
defined by separate documents.The receiving node, based on the OAM Type, will check to see if
a corresponding technology-specific OAM configuration sub-TLV is
included in the OAM Configuration TLV. If the included
technology-specific OAM configuration sub-TLV is different
from what is specified in the OAM Type, an error MUST be
generated: "OAM Problem/OAM Type Mismatch". IANA
maintains the sub-TLV space in the new "RSVP-TE OAM
Configuration Registry".Note that there is a hierarchical dependency between the OAM
configuration elements. First, the "OAM MEP entities desired" flag
needs to be set. Only when that flag is set MAY an OAM Configuration
TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
object. When this TLV is present, based on the "OAM Type" field, it
MAY carry a technology-specific OAM configuration sub-TLV. If this
hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set
but an OAM Configuration TLV is present), an error MUST be generated:
"OAM Problem/Configuration Error".The OAM Configuration TLV MUST always include a single
instance of the OAM Function Flags Sub-TLV, and it MUST
always be the first sub-TLV. "OAM Function Flags" specifies
which proactive OAM functions (e.g., connectivity
monitoring, loss and delay measurement) and which fault
management signals MUST be established and configured. If
the selected OAM Function or Functions are not supported, an error
MUST be generated: "OAM Problem/Unsupported OAM
Function".OAM Function Flags is a bitmap with extensible length based
on 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 size of the padded TLV in octets. IANA
maintains the OAM Function Flags in the new
"RSVP-TE OAM Configuration Registry". This document defines
the following flags: If technology-specific configuration information is
needed for a specific "OAM Type", then this information is
carried in a technology-specific sub-TLV. Such sub-TLVs are
OPTIONAL, and an OAM Configuration TLV MUST NOT contain more
than one technology-specific sub-TLV. IANA
maintains the OAM technology-specific sub-TLV space in the
new "RSVP-TE OAM Configuration Registry".Administrative Status Information is carried in the
Admin_Status object, which is specified for RSVP-TE in . Administrative Status Information is
described in .Two bits (bit numbers 23 and 24) are allocated by this document 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; additionally, the
management system SHOULD NOT be notified. For a detailed description of
the use of these flags, see .To handle OAM configuration errors, a new Error Code "OAM Problem" (40) is introduced. To refer to specific problems, a
set of Error Values are defined under the "OAM Problem" error
code.If a node does not support the establishment of OAM MEP or MIP
entities it MUST use the error value "MEP establishment not
supported" or "MIP establishment not supported", respectively, in the
PathErr message.If a node does not support a specific OAM technology/solution, it
MUST use the error value "Unsupported OAM Type" in the PathErr
message.If a different technology-specific OAM Configuration TLV is
included than what was specified in the OAM Type, an error MUST be
generated with error value "OAM Type Mismatch" in the PathErr
message.There is a hierarchy between the OAM configuration elements. If
this hierarchy is broken, the error value "Configuration Error" MUST
be used in the PathErr message.If a node does not support a specific OAM Function, it MUST use the
error value "Unsupported OAM Function" in the PathErr message.RSVP-TE extensions for the establishment of point-to-multipoint
(P2MP) LSPs are specified in . A P2MP LSP is
comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L
sub-LSPs are set up between the ingress and egress LSRs and are
appropriately combined by the branch LSRs using RSVP semantics to
result in a P2MP TE LSP. One Path message may signal one or multiple
S2L sub-LSPs for a single P2MP LSP. Hence, the S2L sub-LSPs belonging
to a P2MP LSP can be signaled using one Path message or split across
multiple Path messages.P2MP OAM mechanisms are very specific to the data-plane
technology; therefore, in this document we only highlight the
basic principles of P2MP OAM configuration. We consider only
the root-to-leaf OAM flows, and as such, aspects of the
configuration of return paths are outside the scope of our
discussions. We also limit our consideration to the case where
all leaves must successfully establish OAM entities with
identical configuration in order for the P2MP OAM to be successfully
established. In any case, the discussion set forth below
provides only guidelines for P2MP OAM configuration. However,
at a minimum, the procedures below 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 to set up the whole P2MP tree. In the case when multiple Path
messages are used, the root node is responsible for keeping the OAM
configuration information consistent in each of the sent Path
messages, i.e., the same information MUST be included in all Path
messages used to construct the multicast tree. Each branching node
will propagate the Path message downstream on each of the branches;
when constructing a Path message, the OAM configuration information
MUST be copied unchanged from the received Path message, including the
related Admin_Status bits, LSP attribute flags, and OAM
Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES
and LSP_REQUIRED_ATTRIBUTES objects MUST be copied for the upstream
Path message to the subsequent downstream Path messages.Leaves MUST create and configure OAM sink functions according to
the parameters received in the Path message; for P2MP OAM
configuration, there is no possibility for parameter negotiation on a
per-leaf basis. This is due to the fact that the OAM source function,
residing in the root of the tree, will operate with a single
configuration, which then must be obeyed by all leaves. If a leaf
cannot accept the OAM parameters, it MUST use the RRO Attributes
sub-object to notify the root about the
problem. In particular, if the OAM configuration was successful, the
leaf would set the "OAM MEP entities desired" flag in the RRO
Attributes sub-object in the Resv message. On the other hand, if OAM
entities could not be established, the Resv message should be sent with
the "OAM MEP entities desired" bit cleared in the RRO Attributes
sub-object. Branching nodes should collect and merge the received
RROs according to the procedures described in .
This way, the root, when receiving the Resv message (or messages if
multiple Path messages were used to set up the tree), will have clear
information about which of the leaves could establish the OAM
functions. If all leaves established OAM entities successfully, the
root can enable the OAM message flow. On the other hand, if at some
leaves the establishment was unsuccessful, additional actions will be
needed before the OAM message flow can be enabled. Such action could
be to set up two independent P2MP LSPs:
One LSP with OAM configuration information towards leaves that can
support the OAM function. This can be done by pruning from the
previously signaled P2MP LSP the leaves that failed to set up OAM.The other P2MP LSP could be constructed for leaves without OAM
entities.The exact procedures will be described in technology-specific
documents.IANA maintains a registry called "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Parameters"
with a sub-registry called "Administrative Status Information
Flags".IANA has allocated two new flags as follows:IANA maintains a registry called "Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Parameters" with a
sub-registry called "Attribute Flags".IANA has allocated two new flags as follows:IANA maintains a registry called "Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Parameters" with a
sub-registry called "Attributes TLV Space".IANA has allocated one new TLV type as
follows:IANA maintains a registry called "Resource Reservation
Protocol (RSVP) Parameters" with a sub-registry called "Error
Codes and Globally-Defined Error Value Sub-Codes".IANA has allocated one new Error Code as
follows:The following Error Value sub-codes are defined for this new Error
Code:IANA has created a new registry called "RSVP-TE
OAM Configuration Registry". IANA has created sub-registries as defined in
the following subsections. The registration procedures
specified are as defined in .IANA has created the "OAM Types" sub-registry
of the "RSVP-TE OAM Configuration Registry" as follows:There are no initial values in this registry. IANA shows
the registry as follows:IANA has created the "OAM Sub-TLVs"
sub-registry of the "RSVP-TE OAM Configuration Registry" as
follows:IANA has populated the registry as follows:IANA has created the "OAM Function Flags
Sub-Registry" sub-registry of the "RSVP-TE OAM Configuration
Registry".New values in the registry are allocated by IETF
Review . There is no top value to the
range. Bits are counted from bit 0 as the first bit transmitted.IANA has populated the registry as
follows:The signaling of OAM-related parameters and the automatic
establishment of OAM entities based on RSVP-TE messages add a new
aspect to the security considerations discussed in . In particular, a network element could be
overloaded if a remote attacker targeted that element by sending
frequent periodic messages requesting liveliness monitoring of a
high number of LSPs. Such an attack can efficiently be prevented when
mechanisms for message integrity and node authentication are deployed.
Since the OAM configuration extensions rely on the hop-by-hop exchange
of exiting RSVP-TE messages, procedures specified for RSVP message
security in can be used to mitigate possible
attacks.For a more comprehensive discussion of GMPLS security and
attack mitigation techniques, please see the Security Framework
for MPLS and GMPLS Networks .The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful
comments.IEEE Standard for Local and metropolitan area networks --
Media Access Control (MAC) Bridges and Virtual Bridged Local Area
NetworksIEEE