One document matched: draft-takacs-ccamp-rsvp-te-eth-oam-ext-01.txt
Differences from draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Network Working Group A. Takacs
Internet-Draft B. Gero
Intended status: Standards Track Ericsson
Expires: August 28, 2008 February 25, 2008
GMPLS RSVP-TE Extensions to Control Ethernet OAM
draft-takacs-ccamp-rsvp-te-eth-oam-ext-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Takacs & Gero Expires August 28, 2008 [Page 1]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work is
extending GMPLS RSVP-TE to support the establishment of Ethernet
LSPs. Ethernet Connectivity Fault Management (CFM) specifies an
adjunct OAM flow to check connectivity in Ethernet networks. CFM can
be also used with Ethernet LSPs for fault detection and triggering
recovery mechanisms. This memo specifies extensions of GMPLS RSVP-TE
to support the setup of the associated CFM OAM entities for point-to-
point Ethernet LSPs.
Takacs & Gero Expires August 28, 2008 [Page 2]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
Requirements Language
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
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivations and asumptions . . . . . . . . . . . . . . . . . . 5
3. Overview of Ethernet OAM operation in PBB-TE networks . . . . 7
4. Scope of the RSVP-TE extensions . . . . . . . . . . . . . . . 9
5. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 10
5.1. Operation overview . . . . . . . . . . . . . . . . . . . . 10
5.2. Ethernet OAM Configuration TLV . . . . . . . . . . . . . . 12
5.2.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 13
5.2.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 14
5.2.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 15
5.3. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 15
5.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Takacs & Gero Expires August 28, 2008 [Page 3]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
1. Background
Provider Backbone Bridging - Traffic Engineering (PBB-TE)
[IEEE-PBBTE] decouples the Ethernet data and control planes by
explicitly supporting external control/management mechanisms to
configure static filtering entries in bridges and create explicitly
routed Ethernet connections. In addition PBB-TE defines mechanisms
for 1:1 protection switching of bidirectional Ethernet connections.
Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE-CFM]. With PBB-TE Ethernet networks will support
explicitly-routed Ethernet connections. CFM can be used to track the
liveliness of PBB-TE connections and detect data plane failures.
In IETF the GMPLS controlled Ethernet Label Switching (GELS)
[GELS-Framework] work is extending the GMPLS control plane to support
the establishment of point-to-point PBB-TE data plane connections.
We refer to GMPLS established PBB-TE connections as Ethernet LSPs.
GELS enables the application of MPLS-TE and GMPLS provisioning and
recovery features in Ethernet networks.
MPLS OAM requirements are described in [RFC4377]. It provides
requirements to create consistent OAM functionality for MPLS
networks. The GMPLS OAM requirements are described in [GMPLS-OAM].
The GMPLS OAM requirements are based on the MPLS OAM requirements
[RFC4377], in addition it also considers the existing OAM techniques
in non-packet networks. This memo discusses the basic aspects of
Ethernet OAM and specifies RSVP-TE extensions addressing OAM
requirements for Ethernet networks.
Takacs & Gero Expires August 28, 2008 [Page 4]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
2. Motivations and asumptions
The following list is an excerpt of MPLS OAM requirements documented
in [RFC4377]. Only a few requirements are discussed that bear a
direct relevance to the discussion set forth in this memo and which
also motivated the extensions specified in this document.
o It is desired to support the automation of LSP defect detection.
It is especially important in cases where large numbers of LSPs
might be tested.
o In particular some LSPs may require automated ingress-LSR to
egress-LSR testing functionality, while others may not.
o Mechanisms are required to coordinate network responses to
defects. Such mechanisms may include alarm suppression,
translating defect signals at technology boundaries, and
synchronising defect detection times by setting appropriately
bounded detection timeframes.
Generally, the frequency of OAM execution must be set properly, to
achieve the OAM requirements. When periodic messages are used for
liveliness check of LSPs the frequency of messages must be set
properly fulfilling the requirements of the service and/or meeting
the detection time boundaries posed by possible congruent
connectivity check operations of higher layer applications.
Furthermore, for consistent measurement of Service Level Agreements
(SLAs) it may be required that measurement points agree on a common
probing rate to avoid measurement problems.
In order for Ethernet LSPs to provide reliable service delivery, data
plane fault detection mechanisms are needed to trigger recovery
actions. Note that if lower layer fault detection (or protection)
mechanisms (such as those supported by SONET/SDH) are available, we
may rely on them and alleviate the need for frequent OAM message
exchanges for liveliness checks of Ethernet LSPs. However, when -
for example - Ethernet is deployed over a WDM optical layer that does
not provide the SONET/SDH protection characteristics, failure
detection and recovery must be solved in the Ethernet layer.
We assume that in networks where PBB-TE and GELS will be deployed the
default LSP path fault detection mechanism will be based on CFM
Connectivity Check Message (CCM) flows.
Fast fault detection and recovery are key to reliable service
delivery. However, there is a trade-off between fast fault detection
and signalling and processing overhead of connectivity monitoring
flows. Today, networks are providing transport of multiple service
Takacs & Gero Expires August 28, 2008 [Page 5]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
types each with special requirements on quality of service including
the requirements on recovery. To balance the tradeoff between fast
detection and overhead it is essential that fault detection and
recovery are matching the requirements of the supported service, as
highlighted in [RFC3469]. For example, while business services may
require sub-second protection switching best effort Internet traffic
may rely on slower (in the order of seconds) restoration mechanisms.
These different requirements are reflected in the frequency of
connectivity monitoring packets that are needed to be exchanged over
the Ethernet LSP supporting a particular service type.
We assume that - for a network operator to be able to balance the
trade-off in fast failure detection and overhead - it will be
beneficial to configure the frequency of CCM messages on a per
Ethernet-LSP basis. Additionally, to simplify network management and
reduce the risk (and impact) of misconfiguration, it is desirable to
use Ethernet LSP signaling to configure CFM at both ends of the LSP
automatically.
Takacs & Gero Expires August 28, 2008 [Page 6]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
3. Overview of Ethernet OAM operation in PBB-TE networks
For the purposes of this document, we only discuss Ethernet OAM
[IEEE-CFM] aspects that are relevant for the connectivity monitoring
point-to-point PBB-TE connections.
PBB-TE [IEEE-PBBTE] defines point-to-point Ethernet Switched Paths
(ESPs) as a provisioned traffic engineered unidirectional
connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-
VID] where the ESP-MAC DA is the destination address of the ESP, the
ESP-MAC SA is the source address of the ESP, and the ESP-VID is a
VLAN identifier allocated for explicitly routed connections. To form
a bidirectional PBB-TE connection two co-routed point-to-point ESPs
are combined. The combined ESPs must have the same ESP-MAC addresses
but may have different ESP-VIDs.
Note that although it would be possible to use GMPLS to setup a
single unidirectional ESP, the Ethernet OAM mechanisms are only full
functional when bidirectional connections are established with co-
routed ESPs. Hence, we focus on bidirectional point-to-point PBB-TE
connections.
At both ends of the bidiretional point-to-point PBB-TE connection one
Maintenance Endpoint (MEP) is configured. The MEPs monitoring a
PBB-TE connection must be configured with the same Maintenance Domain
Level (MD Level) and Maintenance Association Identifier (MAID). Each
MEP has a unique identifier, the MEP ID. Besides these identifiers a
MEP monitoring a PBB-TE connection must be provisioned with the
3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs.
MEPs exchange Connectivity Check Messages (CCMs) periodically with
fixed intervals. Eight distinct intervals are defined in [IEEE-CFM]:
Takacs & Gero Expires August 28, 2008 [Page 7]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
+---+--------------------+----------------+
| # | CCM Interval (CCI) | 3 bit encoding |
+---+--------------------+----------------+
| 0 | Invalid | 000 |
| | | |
| 1 | 3 1/3 ms | 001 |
| | | |
| 2 | 10 ms | 010 |
| | | |
| 3 | 100 ms | 011 |
| | | |
| 4 | 1 s | 100 |
| | | |
| 5 | 10 s | 101 |
| | | |
| 6 | 1 min | 110 |
| | | |
| 7 | 10 min | 111 |
+---+--------------------+----------------+
Table 1: CCM Interval encoding
If 3 consecutive CCM messages are not received by one of the MEPs it
declares a connectivity failure and signals the failure in subsequent
CCM messages, by setting the Remote Defect Indicator (RDI) bit, to
the remote MEP. If a MEP receives a CCM message with RDI set it
immediately declares failure. The detection of a failure may trigger
protection switching mechanisms or my be signalled to a management
system. However, what happens once a failure is detected is out of
the scope of this document.
Takacs & Gero Expires August 28, 2008 [Page 8]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
4. Scope of the RSVP-TE extensions
Although the setup of both unidirectional and bidirectional Ethernet
LSPs is feasible, due to the symmetric bidirectional connectivity
requirement of CFM, we only consider bidirectional point-to-point
Ethernet LSPs. The applicability for multipoint Ethernet LSPs is for
further study.
Note that in addition to Connectivity Check, which is the focus of
this memo, CFM defines Link Trace and Loopback mechanisms as well.
The proposed extension automatically creates the MEPs and associates
them to the LSP. Once the MEPs are created the Link Trace and
Loopback functionality is available for on demand OAM actions.
Whether additional parameters besides those specified in the next
sections are required (or are beneficial) to support Link Trace
and/or Loopback is for further study. In addition parameters needed
to support measurement of Service Level Agreements (SLAs) is also
left for further study. Hence additional parameters may be defined
in subsequent versions of this document.
Note also, that it has been discussed that the extensions defined may
be applicable to other fault detection mechanisms that use periodic
Hello messages, e.g., BFD, as well. However, it is not clear whether
there is a need to bootstrap BFD sessions using RSVP-TE. As such BFD
related discussions and extensions are left for further study.
Takacs & Gero Expires August 28, 2008 [Page 9]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
5. GMPLS RSVP-TE Extensions
5.1. Operation overview
To simplify the configuration of connectivity monitoring, when an
Ethernet LSP is signalled the associated MEPs should be automatically
established. Further more, GMPLS signalling should be able to
enable/disable connectivity monitoring of a particular Ethernet LSP.
To monitor an Ethernet LSP a set of parameters must be provided to
setup a Maintenance Association and related MEPs.
o A unique MAID must be allocated for the PBB-TE connection and both
MEPs must be configured with the same information. The MAID
consists of a Maintenance Domain Name (MD Name) and a Short
Maintenance Association Name (Short MA Name). Various formating
rules for these names have been defined by [IEEE-CFM]. Since
these information is also carried in all CC messages, the combined
length of the Names is limited to 44 bytes. How these parameters
are determined is out of scope of this document.
o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely
identifies a given MEP within a Maintenance Association. That is,
the combination of MAID and MEP ID must uniquely identify a MEP.
How the value of the MEP ID is determined is out of scope of this
document.
o The Maintenance Domain Level (MD Level) allows hierarchical
separation of monitoring entities. [IEEE-CFM] allows
differentiation of 8 levels. How the value of the MD Level is
determined is out of scope of this document. Note that most
probably for all Ethernet LSPs a single (default) MD Level should
be used.
o The desired CCM Interval must be specified by the management
system based on service requirements or operator policy. The same
CCM Interval must be set in each of the MEPs monitoring a given
Ethernet LSP. How the value of the CCM Interval is determined is
out of scope of this document.
o The desired CCM priority to be set by MEPs for the CCM frames can
be specified. How CCM priority is determined is out of scope of
this document.
o MEPs must be aware of their own and the reachability parameters of
the remote MEP. In the case of bidirectional point-to-point
PBB-TE connections this requires that the 3-tuples [ESP-MAC A,
ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are
Takacs & Gero Expires August 28, 2008 [Page 10]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
configured in each MEP. The GMPLS Ethernet Label as defined in
[Fedyk-GELS-PBBTE] consists of the ESP-MAC DA and ESP-VID. Hence
the necessary reachability parameters for the MEPs can be obtained
form Ethernet Labels (i.e., carried in the "downstream" and
upstream labels).
Assuming the procedures described in [Fedyk-GELS-PBBTE] for
bidirectional Ethernet LSP establishment the MEP configuration should
be as follows. When the RSVP-TE signalling is initiated for the
bidirectional Ethernet LSP the local node generates a Path message
and:
o Allocates an Upstream Label from its MAC address (ESP-MAC A) and
locally selected VID (ESP-VID1);
o Inserts an Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES
object, specifying the CCM Interval and MD Level;
o Adds an MD Name Sub-TLV and a Short MA Name Sub-TLV to the
Ethernet OAM Configuration TLV, that will unambiguously identify a
Maintenance Association for this specific PBB-TE connection. Note
that values for these parameters may be derived from the GMPLS LSP
identification parameters;
o Adds a MEP ID Sub-TLV to the Ethernet OAM Configuration TLV. It
selects two distinct integer values to identify the local and
remote MEPs within the Maintenance Association created for
monitoring of the point-to-point PBB-TE connection.
Once the remote node receives the Path message it can use the
UPSTREAM_LABEL to extract the reachability information of the
initiator. Then it allocates a LABEL by selecting the MAC address
(ESP-MAC B) and VID (ESP-VID2) it would like to use to receive
traffic. These parameters determine the reachability information of
the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-
VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the
Ethernet Labels. In addition the information received in the
Ethernet OAM Configuration TLV is used to configure the local MEP.
Once the Resv message successfully arrives to the initiator it can
extract the remote side's reachability information from the LABEL
object whereby this node has also obtained all the information needed
to establish its local MEP.
Once the MEPs are established the monitoring of the LSP is
operational. In certain situations, e.g., maintenance, re-
optimisation of LSPs, it is desirable to explicitly enable or disable
the monitoring of LSPs (i.e., start/stop exchanging CC messages). To
Takacs & Gero Expires August 28, 2008 [Page 11]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
allow administrative control of LSP monitoring one bit in the
ADMIN_STATUS Object is used. The "Monitoring Disabled" (M) bit is
allocated for this purpose.
Note that since the reachability information could be extracted form
the Ethernet Labels it is an option not to use any extension to
support MEP configuration of Ethernet LSPs. That is, an
implementation could use default parameters for CCM intervals and
determine Maintenance Association and MEP identification parameters
automatically from LSP identification information. However, we
rejected this approach, as it does not provide means to set the CCM
interval on a per LSP bases, leaving limited possibilities to
configure CFM in a way that matches the supported services'
requirements. Moreover, there is no way for providing additional
parameters to configure other aspects of Ethernet OAM, e.g.,
Performance Monitoring.
5.2. Ethernet OAM Configuration TLV
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. [RFC4420]
defines a new object for RSVP-TE messages to allow the signalling of
arbitrary attribute parameters making RSVP-TE easily extensible to
support new applications. Furthermore, [RFC4420] allows options and
attributes that do not need to be acted on by all Label Switched
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
signalled transparently, and only examined at those points that need
to act on them. The LSP_ATTRIBUTES object and the
LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide
means to signal LSP attributes and options in the form of TLVs.
Options and attributes signalled 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 [RFC4420]: the Attributes Flags TLV.
Since the extensions defined for CFM Continuity Check are required to
be processed only by the edge nodes while internal nodes need to pass
on the information transparently, the LSP_ATTRIBUTES object should be
used to carry the new TLV for Ethernet OAM configuration information
signalling.
A new TLV, the Ethernet OAM Configuration TLV (depicted below) is
defined to be used to setup CFM entities of Ethernet LSPs. The
Ethernet OAM Configuration TLV is carried in the LSP_ATTRIBUTES
Takacs & Gero Expires August 28, 2008 [Page 12]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
object in Path messages. This new TLV accommodates information on
CCM interval and carries sub-TLVs. If the Ethernet OAM Configuration
TLV is included in the LSP_ATTRIBUTES object this signals the request
that MEPs should be established for the LSP. If MEPs cannot be
established, due to any reason, an error must be generated.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Prio | CCM I | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the Ethernet OAM Configuration TLV (2)
(IANA to define).
Length: indicates the total length including sub-TLVs.
Version: identifies the CFM protocol version according to [IEEE-CFM].
MD L. (MD Level): indicates the desired MD Level. The values are
according to [IEEE-CFM].
Prio: Indicates the priority to be set for CCM frames. In Ethernet
in VLAN TAGs 3 bits are defined to carry priority information.
CCM I (CCM Interval): CCM Interval, according to the 3 bit encoding
[IEEE-CFM] shown in Table 1.
5.2.1. MD Name Sub-TLV
The MD Name sub-TLV is depicted below.
Takacs & Gero Expires August 28, 2008 [Page 13]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
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 (1) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MD Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1, MD Name Sub-TLV (IANA)
Format: according to [IEEE-CFM].
MD Name: variable length field, formatted according to the format
specified in the Format field.
If an undefined Format is specified an error must be generated. Also
the combined length of MD Name and Short MA Name must be less or
equal to 44bytes, if this is violated an error must be generated.
Note that it is allowed to have no MD Name, in this case the MA Name
must uniquely identify a Maintenance Association.
5.2.2. Short MA Name Sub-TLV
The Short MA Name sub-TLV is depicted below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Short MA Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2, Short MA Name Sub-TLV (IANA)
Format: according to [IEEE-CFM].
Short MA Name: variable length field formatted according to the
format specified in the Format field.
Takacs & Gero Expires August 28, 2008 [Page 14]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
If an undefined Format is specified an error must be generated. Also
the combined length of MD Name and Short MA Name must be less or
equal to 44bytes, if this is violated an error must be generated.
Note that it is allowed to have no MD Name, in this case the MA Name
must uniquely identify a Maintenance Association.
5.2.3. MEP ID Sub-TLV
The MEP ID Sub-TLV is depicted below.
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 (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID | Remote MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3, MEP ID Sub-TLV (IANA)
Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID on the initiator side.
Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID to be set for the MEP established at the receiving side. This
value is determined by the initiator node. This is possible, since a
new MAID is assigned to each PBB-TE connection, and MEP IDs must be
only unique within the scope of the MAID.
5.3. Monitoring Disabled - Admin_Status bit
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].
One bit is allocated for the administrative control of OAM
monitoring. In addition to the Reflect (R) bit, 7 bits are currently
occupied (assigned by IANA or temporarily blocked by work in progress
Internet drafts). As the 24th bit (IANA to assign) this draft
introduces the Monitoring Disabled (M) bit. When this bit is set the
connectivity monitoring of the LSP is disabled.
Note that the Monitoring Disabled (M) bit in the ADMIN_STATUS Object
should be technology agnostic and its use is not limited to the
Ethernet related extensions defined in this memo.
Takacs & Gero Expires August 28, 2008 [Page 15]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
5.4. Error handling
Error messages and procedures will be detailed in subsequent versions
of this document.
Takacs & Gero Expires August 28, 2008 [Page 16]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
6. IANA Considerations
This document specifies a new Ethernet OAM Configuration TLV to be
carried in the LSP_ATTRIBUTES objects in Path messages. In addition,
it specifies sub-TLVs within the new TLV.
One bit (Monitoring Disabled (M)) needs to be allocated in the
ADMIN_STATUS Object.
Takacs & Gero Expires August 28, 2008 [Page 17]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
7. Security Considerations
The signalling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent
versions of this document.
Takacs & Gero Expires August 28, 2008 [Page 18]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
8. Acknowledgements
The authors would like to thank Adrian Farrel, Loa Andersson and Eric
Gray for their useful comments.
Takacs & Gero Expires August 28, 2008 [Page 19]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
9. References
[Fedyk-GELS-PBBTE]
"GMPLS control of Ethernet", Internet Draft, work in
progress.
[GELS-Framework]
"GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress.
[GMPLS-OAM]
"OAM Requirements for Generalized Multi-Protocol Label
Switching (GMPLS) Networks", Internet Draft, work in
progress.
[IEEE-CFM]
"IEEE 802.1ag, Draft Standard for Connectivity Fault
Management", work in progress.
[IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress.
[RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003.
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4377] "Operations and Management (OAM) Requirements for Multi-
Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006.
[RFC4420] "Encoding of Attributes for Multiprotocol Label Switching
(MPLS) Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
Takacs & Gero Expires August 28, 2008 [Page 20]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
Authors' Addresses
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Balazs Gero
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: balazs.gero@ericsson.com
Takacs & Gero Expires August 28, 2008 [Page 21]
Internet-Draft GMPLS based Ethernet OAM Control February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Takacs & Gero Expires August 28, 2008 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 11:41:51 |