One document matched: draft-koike-ietf-mpls-tp-oam-maintenance-points-01.txt
Differences from draft-koike-ietf-mpls-tp-oam-maintenance-points-00.txt
MPLS Working Group Y.Koike
Internet Draft NTT
M.Paul
Deutsche Telekom
Intended status: Informational
Expires: September 9, 2010 March 8, 2010
MPLS-TP OAM Maintenance Points
draft-koike-ietf-mpls-tp-oam-maintenance-points-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.
Koike and al Expires October 11, 2010 [Page 1]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Abstract
MPLS transport profile (MPLS-TP) is designed to enable carrier grade
packet transport and complement converged packet network deployments.
Among the most important features of MPLS-TP are comprehensive OAM
functions which enable network operators or service providers to
provide various kinds of service characteristics such as prompt fault
location, substantial survivability, performance monitoring and
preliminary or in-service measurements.
For the realization of those features by the MPLS Transport Profile,
the definition of the maintenance points at which OAM messages are
initiated, terminated and processed is very important. Based on the
MPLS-TP OAM requirements this document elaborates on and gives
guidance about maintenance points in MPLS-TP networks.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Table of Contents
1. Introduction................................................4
2. Conventions used in this document............................4
2.1. Terminology............................................5
2.2. Definitions............................................5
3. General characteristics of maintenance operations in transport
networks.......................................................5
4. Location of maintenance points...............................6
4.1. Types of MEP location...................................7
4.1.1. Per-node MEP.......................................7
4.1.2. Per-interface MEP..................................7
4.2. Types of MIP location...................................8
4.2.1. Per-node MIP.......................................8
4.2.2. Per-interface MIP..................................9
5. Dependency of OAM capability and the location of maintenance
points........................................................10
5.1. Fault location........................................12
5.2. Performance Monitoring.................................14
6. Analysis of MEP&MIP location for different OAM functions.....14
6.1. Continuity Check.......................................15
6.2. Connectivity Verifications.............................15
Koike et al. Expires September 9, 2010 [Page 2]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
6.3. Route Tracing.........................................15
6.4. Diagnostic Test........................................16
6.5. Lock Instruct.........................................16
6.6. Lock Reporting........................................16
6.7. Alarm Reporting........................................16
6.8. Remote Defect Indication...............................16
6.9. Client Failure Indication..............................16
6.10. Packet Loss Measurement...............................17
6.11. Packet Delay Measurement..............................17
7. Requirements for the location of MPLS-TP OAM maintenance points18
8. Security Considerations.....................................18
9. IANA Considerations........................................18
10. References................................................18
10.1. Normative References..................................18
10.2. Informative References................................20
11. Acknowledgments...........................................20
Koike et al. Expires September 9, 2010 [Page 3]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
1. Introduction
A packet transport network will enable carriers or service providers
to use network resources efficiently and reduce network cost. For
carrier grade network operation appropriate maintenance operations
such as prompt fault location, substantial survivability, performance
monitoring, preliminary and in-service measurement are essential
factors to ensure quality and reliability of the network. These
operational characteristics are essential features of transport
networks and have evolved long with TDM evolution, ATM, SDH and OTN.
Unlike in SDH or OTN networks where OAM is an inherent part of every
frame and frames being also transmitted in idle mode, in packet
networks it is not per se possible to constantly monitor the status
of individual connections. In other words, packet transport networks
rely on additional measures, i.e. OAM functions and proper location
of maintenance points. On the other hand, packet based OAM functions
are flexible and selectively configurable to operator's needs.
According to the MPLS-TP OAM requirements [6] mechanisms MUST be
available for a service provider to be aware of a fault or defect
affecting the service(s) he provides.
To ensure that faults can be localized and connections can be traced
through network elements, links, intra-domain and inter-domain
interfaces, it is important to define the appropriate location of OAM
maintenance points which are responsible for processing OAM messages
and performing OAM functions. If maintenance points are not defined
properly, any excellent OAM function for pro-active and on-demand
maintenance may become meaningless or less effective.
In addition, it is also important to clarify how those OAM
maintenance points are utilized by each maintenance mechanism, in
other words, each OAM function. If OAM processing at each OAM
maintenance point is not clarified, network management view and
operability of network elements might be unsufficient.
This document clarifies requirements on OAM maintenance points by
elaborating on the technical background and on deployment cases.
Moreover requirements for every OAM function are also clarified based
on the newly introduced deployment of maintenance points.
2. Conventions used in this document
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 RFC-2119 [1].
Koike et al. Expires September 9, 2010 [Page 4]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
2.1. Terminology
CE Customer Edge
FW Forwarding Engine
I/F Interface
LSP Label Switched Path
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
NE Network Element
NNI Network-to-Network Interface
OTN Optical Transport Network
PE MPLS-TP Provider Edge LSR
P MPLS-TP Provider LSR
SDH Synchronous Digital Hierarchy
UNI User-to-Network Interface
2.2. Definitions
Most of the definitons in this draft follow those definitions in [7].
3. General characteristics of maintenance operations in transport
networks
The following two characteristics (C1-C2) are significant in
transport networks.
C1) When a fault occurs with client traffic, it must be possible to
locate the cause of the fault or defect in client data traffic, that
Koike et al. Expires September 9, 2010 [Page 5]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
is, whether it is within one administrative domain or outside the
domain.
If a fault occurs in client traffic, it is necessary to identify
whether the cause is within the responsible operator's administrative
domain or outside of it. Immediate fault identification and location
is an important factor for providing effective maintenance actions
and avoiding high efforts for manual interventions.
Therefore, C1 is an inevitable characteristic of the transport
profile.
C2) When a fault or a defect occurs in a connection within one
administrative domain, it must be possible to locate whether the
cause is within a node or between two neighboring nodes.
If the fault is within one administrative domain, the next action is
to determine if the problem is located within one node or
transmission line, i.e. to determine whether it is an equipment alarm
or communication alarm. The basic reason the two alarms are
separately defined in a transport network is dependent on the
characteristic difference of the two network components, the node or
the transmission line. The performance and quality of the network
node is mainly determined by the switching or forwarding component,
whose implementation can differ among system vendors. The performance
and quality of the transmission line is mainly determined by the line
card/IF component and physical transmission media. The line card/IF
package is more generalized and less vendor specific as forwarding
and switching components. Accordingly, the separation between the
switching and transmission section is quite reasonable from the
perspective of architectural design.
When a fault is detected, it MUST be possible to locate the affected
component or narrow the causes of the fault. This enables prompt and
well-directed actions, by e.g. a replacment of packages/line
cards/modules or by changing settings of the package, port, section,
or connection unit. Efficiently handling this problem and avoiding
any effect on other client traffic, which does not encounter faults
and is not related to the fault, are important.
4. Location of maintenance points
OAM maintenance points need to be specified clearly in order to meet
the MPLS-TP OAM requirements [6] and the characteristics described in
section 3 of this draft. OAM maintenance points include MEP and MIP.
Koike et al. Expires September 9, 2010 [Page 6]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
4.1. Types of MEP location
Note: Following sections will be copied to section 3.2 MEG End Points
(MEPs) of OAM framework[7].
An end node within a point-to-point MEG will support per-node MEP or
per-interface MEP.
4.1.1. Per-node MEP
Per-node MEP is a MEP which is located somewhere within one NE. There
is no other MIP on the same LSP/PW within the same NE.
Source/Destination node
-----------------
| |
| ----- |
| | | |
->-| | MEP | |->-
| | | |
| ----- |
| |
-----------------
Figure.1: Per-node MEP
In this case, the location of MEP within NE is unspecified. In other
words, MEP is located at ingress interface(I/F), forwarding
engine(FW), egress I/F, or other parts, if any.
Note: It is said that most common implementation of MEP in LSP/PW is
located at ingress interface and the second common one is located at
FW. However, per-node MEP doesn't restrict its location within one NE.
4.1.2. Per-interface MEP
Per-interface MEP is a MEP which is located on the interface facing
the client network (UNI) and being specified independently from
forwarding engine.
In the most cases, a per-interface MEP will be combined with a per-
interface MIP which is located on the interface facing the provider
network (NNI) on the same LSP/PW within the same NE.
Koike et al. Expires September 9, 2010 [Page 7]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Source/Destination node Source/Destination node
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MEP | | | | | | MEP |
| | ---- | | | | ---- | |
->-| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(1) (2)
Figure.2: Per-interface MEP: (1)Ingress per-interface MEP and (2)
egress per-interface MEP in source/destination node
Figure 2 shows two examples of per-interface MEP at
source/destination node of LSP/PW. In left hand case (1) in fig.2,
the destination/source MEP is located at the ingress interface before
the FW in the source node and in right hand case (2) in fig.2, the
source/destination MEP is located at the egress interface after the
FW in destination/source node.
4.2. Types of MIP location
Note: Following sections will be copied to section 3.3 MEG
Intermediate Points (MIPs) of the MPLS-TP OAM framework[7].
An end or intermediate node within a point-to-point MEG will support
per-node MIP or per-interface MIP.
4.2.1. Per-node MIP
Per-node MIP is a MIP which is located somewhere within one NE. There
is no other MIP on the same LSP/PW within the same NE.
Intermediate node
-----------------
| |
| ----- |
| | | |
->-| | MIP | |->-
| | | |
| ----- |
| |
-----------------
Koike et al. Expires September 9, 2010 [Page 8]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Figure.3: Per-node MIP
Fig.3 shows the per-node MIP model. In this model, the location of
MIP within a node is unspecified. In other words, MIP is located at
ingress interface (I/F), forwarding engine (FW), egress I/F or other
part if any.
Note: In the most cases, per-node MIPs for LSP/PW are located at
ingress interface or at the FW. However, the location of per-node
MIPs within one NE isn't constrained to that.
4.2.2. Per-interface MIP
Per-interface MIP is a MIP which is located on a node interface,
independently from the forwarding engine.
In the most cases, per-interface MIP will be combined with another
per-interface MIP which is located on the egress interface of the
same LSP/PW within the same NE.
Intermediate node
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Figure.4: Per-interface MIP: ingress MIP and egress MIP
Figure 4 shows per-interface MIP model. This model has one MIP placed
at the ingress interface and one MIP placed at the egress interface
at a source/intermediate/destination node of LSP/PW. An ingress MIP
is located at the ingress interface before the FW in an
intermediate/destination node and an egress MIP is located at the
egress interface after the FW in a source/intermediate node.
Koike et al. Expires September 9, 2010 [Page 9]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
5. Dependency of OAM capability and the location of maintenance points
In this section, the difference of OAM functional capabilities
between type1 and type2 of locations of maintenance points are
described.
One of the most important features for maintenance operation is to
appropriately set and use points at which fault location, performance
monitoring or diagnostic test is done. As described in section 4,
there are mainly two different assignments of maintenance points,
that is, type1 and type2. In case of type 1 MIP or MEP, only one
maintenance point exists somewhere within a node. In case of type2
MIP or MEP, two maintenance points exist per node, i.e. one at the
ingress interface and one at the egress interface.
Following section shows the comparison of OAM maintenance
capabilities between type1 and type2. For type 1, the location of a
maintenance point (MIP or MEP) is not specified within one NE. Type1
is basically classified into two options (located at ingress
interface or at the forwarding engine), when currently deployed
implementations are considered. The most common location of
maintenance point of LSP/PW is at ingress interface. Therefore the
location of maintenance point is assumed at ingress interface in the
following comparisons.
Customer| Operator's administrative | Customer
Domain | Domain | Domain
------> |<------------------------------------ ->| <------
CE1 | PE1 P1 PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD LSP | o---------------------------> |
| V-------------*-------------V |
| MEP1 MIP1 MEP2 |
BWD LSP | <---------------------------o |
| V-------------*-------------V |
| MEP1' MIP1' MEP2'|
(S1)<============>
(S2)<==========================>
Figure.5: Example of per-node MIP and MEP
Koike et al. Expires September 9, 2010 [Page 10]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Customer Operator's administrative Customer
Domain Domain Domain
------->|<--------------------------------------->|<------
CE1 | PE1 P1 PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD LSP | o-----------------------------------> |
| V-------*------*------*-----*-------V |
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
| |
BWD LSP | <-----------------------------------o |
| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
(S'1)<======>
(S'2)<=============>
(S'3)<====================>
(S'4)<==========================>
(S'5)<==================================>
Figure.6: Example of per-interface MIP and MEP
Koike et al. Expires September 9, 2010 [Page 11]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Fig.5 shows the per-node model of maintenance points when some
connection service is provided between CE1 and CE2. A LSP is
established between PE1 and PE2. MEP1 in forward direction and MEP1'
in backward direction are located within a same PE1. In the same
manner, a pair of MIP1 and MIP1' and a pair of MPE2 and MEP2' are
located within a same P1 and PE2 respectively.
In fig.5, MIP and MEP at each label edge router (LER) is located at
different position within the router in forward direction and
backward direction respectively for comparison between per-node
MIP&MEP(fig.5) and per-interface MIP&MEP(fig.6). Strictly speaking,
in forward direction MEP1 is set at ingress interface of PE1 and MEP2
is set at ingress interface of PE2. MIP1 is set at ingress interface
P1. Moreover, MIP1', MEP1' and MEP2' in unidirectional LSP of
backward direction from egress interface of PE2 to egress interface
of PE1 is also described.
Figure 6 shows the per-interface model of maintenance points when
some connection service is provided between CE1 and CE2. A LSP is set
between PE1 and PE2. In forward direction, MEP1 is set at ingress
interface(In) of PE1 and MEP2 is set at egress interface(Out) of PE2.
MIP1 is set at egress interface of PE1, MIP2 is at in-I/F of P2, MIP3
is at out-I/F of P3, MIP4 is at in-I/F of PE2. Moreover, LSP of
backward direction from out-I/F of PE2 to in-I/F of PE1 is also
described. In this case, MIPs and MEPs at each label edge router are
located at the same position within the router in forward direction
and backward direction respectively.
5.1. Fault location
The following two cases based on Fig.5 and Fig.6 compare the
different characteristic between per-node MIP&MEP and per-interface
MIP&MEP in terms of fault location. Locations of maintenance points
in per-node MIP&MEP in fig.5 can cause two concrete problems,
relating to characteristics (C1) and (C2) in section 3.
The following 2 cases are considered, where on-demand CV is
exemplified as mechanism for fault location:
Case 1: Customer traffic between CE1 and CE2 contains a fault and on-
demand CV from PE1 to PE2 is OK
Case 2: On-demand CV from PE1 to P fails (NG).
Koike et al. Expires September 9, 2010 [Page 12]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
Case 1 highlights a scenario where the fault is located in the client
domain or operator domain. The suspected fault points are forwarding
engine(FW) in PE2, out-going interface(Out) in PE2, transmission line
between PE2 and CE2 or CE2.
In case of the per-node model in fig.5, on-demand CV can only be
performed on segment2(S2). With only one maintenance point per node,
it is impossible to precisely identify the fault location.
In case of per-interface model in fig.6, there are five segments
where on-demand CV can be performed. Although S2 in fig.5 corresponds
to S4' in fig.6, on-demand CV can also be conducted in S'5 in case of
per-interface model in fig.6. Adding MEP2 in PE2 enables to obtain
additional information and more precisely locate the fault by using
on-demand CV.
If the result of on-demand CV in S4' is OK, the fault location range
can be limited to the transmission line between ME2 and CE2 or out-
going IF(Out) in PE2. If the result of on-demand CV in S4' is NG, the
fault is at egress IF(Out) in PE2 or at the forwarding engine in PE2.
In packet network, miss-configuration might be the cause of
connection fault more often than hardware failure of packages. As a
result, per-interface model provide more effective fault location
function than per-node model.
Per-interface model makes it easy to locate the cause of the fault or
defect in client data traffic, that is, whether it is within one
administrative domain or outside the domain.
Note: Interaction with client OAM / attachment circuit has to be done
on another OAM level, i.e. by link OAM or an end-to-end service OAM
on the client service layer and by OAM message mapping. This is for
further study.
Case 2 highlights a scenario where the fault is located on the
interface or transmission line within operator's domain.
In case of the per-node model in fig.5, segment1 (S1) is the only
pattern where on-demand CV can be performed. With only one
maintenance point per node, it is impossible to precisely identify
the fault location. On the other hand, in case of per-interface model
in fig.6, there are five segments in total where on-demand CV can be
performed. Although S1 in fig.5 corresponds to S2' in fig.6, on-
demand CV can also be conducted in S'1 in case of per-interface model
in fig.6. Adding MIP2 in PE1 enables to obtain additional information
and more precisely locate the fault by using on-demand CV.
Koike et al. Expires September 9, 2010 [Page 13]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
As explained above, setting maintenance points on both sides of the
switch fabric in per-interface model enables operators to locate
faults more precisely and as a result, perform maintenance more
efficiently than in per-node model. Operators have to indentify the
location of MEP particularly in per-node model.
This comparison of maintenance capability is applied to not only on-
demand CV which is exemplified in this section but also other OAM
functions such as a proactive continuity check, proactive on-demand
connectivity verification, on-demand route tracing, on-demand loss
measurement, on-demand delay measurement and diagnostic test.
5.2. Performance Monitoring
According to MPLS-TP OAM requirements, performance monitoring has to
be supported by loss measurement and delay measurement function.
Those are supported between two MEPs.
In case of per-node MEP model as per fig.5, the segment where the
performance of LSP/PW is monitored is S2 between MEP1 and MEP2 in the
forward direction. Therefore, if some degrade happened between In and
Out in PE2, it is impossible to detect the degradation on this
segment.
In case of per-interface MEP model as per fig.6, the measurable
segment is S'5 between MEP1 and MEP2 in the forward direction and
whole connection is covered end-to-end. There is no segment which is
not measurable.
It is highly propable that the LER can become a cause for degradation
of services. In that case, the difference between per-node model and
per-interface model could be critical. Operators have to be careful
about the location of MEP in per-node model.
6. Analysis of MEP&MIP location for different OAM functions
Note: Following sections will be copied to section 5 OAM Functions
for proactive monitoring and to 6. OAM Functions for on-demand
monitoring of the MPLS-TP OAM framework[7]. The most appropriate
destination will be the passages which describe defects for each OAM
function.
Koike et al. Expires September 9, 2010 [Page 14]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
6.1. Continuity Check
There is a difference of defect detection capability between per-
interface and per-node model. In case of per-node model, maintenance
points are not specified with in NE, therefore, there is a
possibility that some defects are not detected depending on the
location of the defect. In case of per-interface model, there is no
missing segment where defects can not be detected, compared with per-
node model.
In addition, in case of per-interface model, it is possible to
differentiate whether the cause of the defect(s) is(are) within one
administrative domain or outside the domain. It is also possible to
differentiate whether the cause is within a node or between two
neighboring nodes.
6.2. Connectivity Verifications
There is a difference of defect detection capability between per-
interface and per-node model. In case of per-node model, maintenance
points are not specified with in NE, therefore, there is a
possibility that some defects are not detected depending on the
location of the defect.
In case of per-interface model, there is no missing segment where
defects can not be detected.
In addition, in case of per-interface model, it is possible to
differentiate whether the cause of the defect(s) is(are) within one
administrative domain or outside the domain. It is also possible to
differentiate whether the cause is within a node or between two
neighboring nodes.
6.3. Route Tracing
There is a difference of route tracing capability between per-
interface and per-node model. In case of per-node model, maintenance
points are not specified with in NE, therefore, there is a
possibility that some segments of the route of client traffic within
operator domain cannot be traced.
In case of per-interface model, there is no missing segment - the
route can be traced completely.
In addition, in case of per-interface model, it is possible to
differentiate whether the point of the failure of the route tracing
is(are) within one administrative domain or outside the domain. It is
also possible to differentiate whether the point is within a node or
between two neighboring nodes.
Koike et al. Expires September 9, 2010 [Page 15]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
6.4. Diagnostic Test
There is a difference of diagnostic capability between per-interface
and per-node model. In case of per-node model, maintenance points are
not specified with in NE, therefore, there is a possibility that some
segments of the route of the client traffic within operator domain
cannot be tested. In case of per-interface model, there is no missing
segment where the diagnostic test can not be conducted.
In addition, in case of per-interface model, it is possible to
differentiate whether the cause of the defect(s) is(are) within one
administrative domain or outside the domain. It is also possible to
differentiate whether the cause is within a node or between two
neighboring nodes.
6.5. Lock Instruct
To be incorporated in a future revision of this document, when this
feature is specified in OAM framework[7].
6.6. Lock Reporting
No difference between per-interface and per-node model.
Function is independent of the location of maintenance points within
one node.
6.7. Alarm Reporting
No difference between per-interface and per-node model.
Function is independent of the location of maintenance points within
one node.
6.8. Remote Defect Indication
No difference between per-interface and per-node model.
Function is independent of the location of maintenance points within
one node.
6.9. Client Failure Indication
No difference between per-interface and per-node model.
CFI is associated with client failure and sent from MEP to MEP as a
result of detection of client signal fail. Therefore, there is no
direct impact on its capability.
Koike et al. Expires September 9, 2010 [Page 16]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
6.10. Packet Loss Measurement
There is a difference of packet loss measurement capability between
per-interface and per-node model. In case of per-node model, the
location of maintenance points is not specified within NE, therefore
there is a possibility that some segments of the route of the client
traffic within operator domain are not measurable. In case of per-
interface model, there is no missing segment where the packet loss
measurement can not be conducted.
In addition, in case of per-interface model, it is possible to
differentiate whether the cause of the defect(s) is(are) within one
administrative domain or outside the domain. It is also possible to
differentiate whether the cause is within a node or between two
neighboring nodes.
6.11. Packet Delay Measurement
There is a difference of packet delay measurement capability between
per-interface and per-node model. In case of per-node model, the
location of maintenance points is not specified within NE, therefore,
there is a possibility that some segments of the route of the client
traffic within operator domain are not measurable. In case of per-
interface model, there is no missing segment where the packet delay
measurement can not be conducted.
In addition, in case of per-interface model, it is possible to
differentiate whether the cause of the defect(s) is(are) within one
administrative domain or outside the domain. It is also possible to
differentiate whether the cause is within a node or between two
neighboring nodes.
Koike et al. Expires September 9, 2010 [Page 17]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
7. Requirements for the location of MPLS-TP OAM maintenance points
According to the MPLS-TP OAM requirements [6] mechanisms MUST be
available for a service provider to be aware of a fault or defect
affecting the service(s) he provides, even if the fault or defect is
located outside of his domain. It is further defined that OAM
information MUST include identifiers related to the nodes and
interfaces composing that route.
MPLS-TP OAM maintenance points need to be specified properly in order
to meet the requirements and characteristics of transport networks,
as highlighted by this draft.
Thus, the following detailed requirements are to be considered in the
MPLS-TP OAM framework and for the MPLS-TP OAM solutions:
1) Per-node and per-interface deployment models MUST be supported.
2) At intermediate nodes, for each PW or LSP it MUST be possible to
set two MIPs; one MIP on the ingress interface and another MIP on the
egress interface.
3) At edge nodes, for each PW or LSP it MUST be possible to set one
MIP and one MEP; one MIP on the interface facing the provider
network(NNI) and one MEP on the interface facing the client network
(UNI).
4) MEPs have to be set at the time when the PW or LSP is provisioned.
MIPs have to be set at any time, when it is necessary or required.
8. Security Considerations
This document does not by itself raise any particular security
considerations.
9. IANA Considerations
There are no IANA actions required by this draft.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Koike et al. Expires September 9, 2010 [Page 18]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
[2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001
[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001
[4] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno,
S., "MPLS-TP Requirements", RFC 5654, September 2009
[5] Bocci, M., et al., "A Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-10 (work in progress), February
2010
[6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
05 (work in progress), February 2010
[7] Busi, I., Niven-Jenkins, B. , "MPLS-TP OAM Framework", draft-
ietf-mpls-tp-oam-framework-04.txt, December 2009
[8] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y.,
"MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-07
(work in progress), October 2009
[9] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node
interface for the synchronous digital hierarchy (SDH)", January
2007
[10] ITU-T Recommendation G.709/Y.1331 (03/03), "Interfaces for the
Optical Transport Network (OTN)", March 2003
[11] ITU-T Recommendation G.805 (03/00), "Generic functional
architecture of transport networks", March 2000
[12] ITU-T Recommendation G.806 (01/09), "Characteristics of
transport equipment - Description methodology and generic
functionality", January 2009
[13] ITU-T Recommendation G.7710 (07/07), "Common equipment
management function requirements", July 2007Bradner, S., "Key
words for use in RFCs to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
Koike et al. Expires September 9, 2010 [Page 19]
Internet-Draft MPLS-TP OAM Maintenance Points March 2010
10.2. Informative References
11. Acknowledgments
The authors would like to thank all members (including MPLS-TP
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
in ITU-T) involved in the definition and specification of MPLS
Transport Profile.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yoshinori Koike (Editor)
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Manuel Paul (Editor)
Deutsche Telekom
Email : Manuel.Paul@telekom.de
Koike et al. Expires September 9, 2010 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 06:52:56 |