MPLS Working Group Y.Koike, Ed.
Internet Draft T.Hamano
M.Namiki
NTT
Intended status: Informational
Expires: May 8, 2013 November 9, 2012
A framework for Point-to-Multipoint MPLS-TP OAM
draft-hmk-mpls-tp-p2mp-oam-framework-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 May 6, 2013.
Copyright Notice
Copyright (c) 2011 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
Koike, et al. Expires May 8, 2013 [Page 1]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Abstract
The MPLS transport profile (MPLS-TP) is being standardized to enable
carrier-grade packet transport.
This document discusses and specifies P2MP framework primarily
related to OAM, management, and recovery. This document is mainly
based on RFC5654 and RFC6371. The main focus is on the details not
covered in relevant RFCs such as RFC5654, RFC5860, RFC5921, RFC5951,
RFC6371 and the draft-fbb-mpls-tp-p2mp-framework. Other requirements
for p2mp transport paths, such as recovery, will also be specified in
a future version on the premise that there are return paths.
Note: This I-D was made and updated based on discussions in ITU-T
SG15, which were described in Liaison Statements: Request advance
work on the P2MP framework in the MPLS-TP
(https://datatracker.ietf.org/liaison/1163/) and Progressing work on
P2MP MPLS-TP connections (https://datatracker.ietf.org/liaison/1202/)
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 ................................................ 3
2. Conventions used in this document............................ 4
2.1. Terminology ............................................ 4
2.2. Definitions ............................................ 5
3. P2MP OAM .................................................... 5
Koike, et al. Expires May 8, 2013 [Page 2]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
3.1. OAM functions for proactive monitoring .................. 6
3.1.1. Continuity Check and Connectivity Verification ...... 8
3.1.2. Remote Defect Indication ........................... 9
3.1.3. Alarm Reporting .................................... 9
3.1.4. Lock Reporting ..................................... 9
3.1.5. Packet Loss Measurement ............................ 9
3.1.6. Packet Delay Measurement ........................... 9
3.1.7. Client Failure Indication .......................... 9
3.2. OAM functions for on-demand monitoring .................. 9
3.2.1. Connectivity verification .......................... 9
3.2.2. Packet loss measurement ........................... 10
3.2.3. Diagnostic tests .................................. 10
3.2.4. Route Tracing ..................................... 10
3.2.5. Packet delay measurement .......................... 10
3.3. OAM functions for administration control ............... 11
3.3.1. Lock Instruct ..................................... 11
4. Security Considerations ..................................... 11
5. IANA Considerations ........................................ 11
6. References ................................................. 11
6.1. Normative References ................................... 11
6.2. Informative References ................................. 11
7. Acknowledgments ............................................ 11
1. Introduction
The demand for P2MP traffic is expected to increase due to the
increase in new services such as IP-TV and video distribution
services. In light of the global trend of improving energy efficiency,
a point-to-multipoint (P2MP) transport function in MPLS-TP could be
one of the solutions for achieving this goal from the perspective of
efficient use of network resources.
RFC5654[1] defines the following requirements that are specific to
P2MP.
Koike, et al. Expires May 8, 2013 [Page 3]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
- Traffic-engineered point-to-multipoint (P2MP) transport paths.(item
6).
- Unidirectional point-to-multipoint(P2MP) transport paths (item 8)
- Being capable of using P2MP server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths(item 40)
- The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e.
unidirectional P2MP) including the configuration of protection
functions and any associated maintenance functions.(item 50)
Unidirectional 1+1 protection for P2MP connectivity (item 65 C)
- Unidirectional 1:n protection for P2MP connectivity(item 67 B)
- MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths.(item 95)
RFC5860 [2] defines MPLS-TP OAM requirements including those for
unidirectional P2MP transport paths. With a unidirectional P2MP
transport path, two cases are assumed as per Section 3.3 of
RFC6371[3]. One is when no return path exists or not used and the
other is when an out-of-band return path exists and used.
In I-D[4], only a summary of various items specific to MPLS-TP P2MP
framework. For example, according to the editor's note, this section
will contain a summary of P2MP OAM, as described in RFC6371 [3],
which defines the overall OAM architecture for MPLS-TP.
Therefore, this draft intends to specify details of a P2MP framework
that complements P2MP requirements and the framework of existing RFCs,
particularly in terms of OAM, management, and recovery.
Note: MPLS-TP functions that are applicable specifically to P2MP
transport paths are outside the scope of RFC5921.
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].
2.1. Terminology
EMS Element management system
LSP Label Switched Path
Koike, et al. Expires May 8, 2013 [Page 4]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
NE Network Element
NMS Network Management System
2.2. Definitions
None
3. P2MP OAM, management and recovery
The support of P2MP OAM on the data path should be independent of the
availability of a return path or the mechanism that supports the
return path. Basically, only unidirectional P2MP is supported in
MPLS-TP. This means that an In-band return path is out of the scope
of MPLS-TP requirements. In this section, two cases, with out-band
return path and without return path, are considered basics and
requirements when return paths exist should be independently
specified from when no return path exists.
P2MP considerations are described in Section 3.7 of RFC6371. The RFC
has already described some requirements with out-band return path(s).
On the other hand, even if there is no return path, most of OAM
requirements in RFC5860 could be met by supporting management
interface through which EMS/NMS can retrieve the received OAM packets.
The return path may be considered to be directed to the entity that
originally requested the measurements because this may not be the
head end of the P2MP connection. Therefore, the following return path
should be distinctly differentiated.
RP-N: A return path to the EMS/NMS through the management
interface (RP-N) (This case is referred to as that in which no
return path exists)
RP-HE: A return path to a head end of a P2MP path using any
kind of out-of-band path (This case is referred to as that in
which an out-of-band return path exists)
These two kinds of return paths may be applied at the same time,
depending on the situations.
Note: In the following sections, additional requirements are
basically described function-by-function, which have not been covered
Koike, et al. Expires May 8, 2013 [Page 5]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
or clarified in RFC5860[2] and RFC6371 [3], which have focused
particularly on when return paths do not exist.
3.1. General aspects of P2MP OAM
P2MP transport paths are unidirectional; therefore, there is
generally no in-band return path as in the MPLS-TP transport path per
se. However, there are basically two approaches for handling OAM
requirements in P2MP MPLS-TP.
The first one is used to report the results of the
monitoring/measurement of OAM packets from the OAM target node to the
EMS/NMS when the NMS usually instantiates OAM functions and requires
the results of OAM monitoring functions. This approach is called RP-N.
The second approach is the return path to a root (source MEP) of a
P2MP path using different methods such as a unidirectional p2p
transport paths, and other technology-layers, such as IP, Ethernet,
and OTN, when an NE within which a root MEP resides instantiates OAM
functions or receive results of OAM monitoring functions. This
approach is called as RP-HE. The following requirements are supported
in terms of network elements when considering RP-N.
1. OAM functions of a MEG of a P2MP transport path should be
configurable using the EMS/NMS.
2. Source nodes at which the source MEP reside and OAM packets are
generated should receive OAM related information such as
enabling/disabling OAM functions and setting/changing OAM
attributes from the EMS/NMS on a P2MP transport path.
3. Sink nodes at which targeting MIPs or MEPs reside and OAM packets
are parsed should report OAM related information such as OAM
monitoring results and consequent OAM actions to the EMS/NMS.
4. Each OAM function of a P2MP transport path should be able to be
independently configured using the EMS/NMS based on the
classification of OAM functional requirements in RFC5860.
5. An on-demand OAM function must be able to perform an OAM function
for only a specific target MIP or MEP as well as all MEPs in a
P2MP transport path, as specified in Section 3.7 of RFC6371[3].
6. To manage M leaves(i.e., subset of all leaves) in an on-demand OAM
function from the EMS/NMS, a unified mechanism must be provided.
Note: Currently, sending an OAM packet that is targeted at a
subset of M leaves by using an aggregating mechanism such as an
Koike, et al. Expires May 8, 2013 [Page 6]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
OAM packet including several MIP or MEP identifiers is out of the
scope of RFC6371[3] as described in Section 3.7 of that document.
7. Mismatches of configuration information between a root MEP and any
leaf-MEP, at which proactive or on-demand monitoring is enabled,
should be detected as a configuration mismatch alarm and be
reported to the EMS/NMS by parsing received OAM packets,
particularly when a static setting is applied.
Generally when each OAM function is enabled, as described in Section
5.1 of RFC6371[3], the source MEP function should be enabled prior to
the corresponding sink MEPs function.
Regarding configuration considerations, the following are additional
requirements for unidirectional P2MP transport path, particularly
when RP-HE does not exist.
8. The configuration of each OAM function between the source MEP and
sink MEP(s) in an MEG of a transport path should be able to be
synchronized using the NMS, when a new P2MP transport path is set.
9. The configuration of newly added/removed specific sink MEP(s)to
the existing source MEP in the MEG in proactive monitoring should
be able to be synchronized with that of the source MEP by using
the NMS.
10.The EMS/NMS should provide a tool for manually configuring
consistent values of each piece of configuration information to a
root MEP and all the related leaf MEPs in a MEG of a P2MP
transport path for both pro-active and on-demand OAM functions.
11.Mismatches of configuration information between a leaf MEP and any
other leaf MEP(s) or a root MEP and leaf MEP(s), at which
proactive monitoring will be enabled, should be able to be
detected through the configuration management process of the
EMS/NMS as a configuration mismatch alarm or notification without
receiving OAM packets from a source MEP(before OAM functions are
enabled).
Note: This requirement is not necessary if the EMS/NMS provides a
tool to manually configure a consistent value of each piece of
configuration information to a root MEP.
12.The enabling or disabling of proactive OAM functions and
configuration mismatch alarms of the OAM functions must be
independently configurable at each leaf-MEP as well as on all the
leaf MEPs on a P2MP transport path, considering maintenances or a
Koike, et al. Expires May 8, 2013 [Page 7]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
case in which one or more leaf MEPs is newly added or removed
later.
13.Mismatches of configuration information between a leaf MEP and any
other leaf MEP(s) or a root MEP and leaf MEP(s), at which on-
demand OAM monitoring is enabled, must be detected as a
configuration management process before conducting OAM functions.
3.2. OAM functions for proactive monitoring
The proactive OAM functions are used to detect a fault/defect or to
automatically reports a change in the status of a transport path.
3.2.1. Continuity Check and Connectivity Verification(CC-V)
The continuity Check function enables one or more leaf MEPs on a
unidirectional P2MP transport path to monitor the continuity of OAM
packets from root MEP and detect one or more loss of continuity(LOC)
defects between the root MEP and leaf MEPs.
The connectivity verification function enables one or more leaf MEPs
on a P2MP transport path to monitor the connectivity of OAM packets
from a specific root MEP and detect an unexpected connectivity defect
between two MEGs(two P2MP transport paths)
As described in Sections 2.2.2 and 2.2.3 of RFC5860[2], CC-V MUST be
supported even when RP-HE does not exist.
As described in RFC6371[3], CC-V OAM packets are used for a P2MP
transport path. Defect detection mechanisms in P2MP transport paths
are the same as those of the P2MP transport path specified in section
5.1.1 of RFC6371 [3]. That is, loss of continuity(LoC) defect, mis-
connectivity defect, period mis-configuration defect and unexpected
encapsulation defect. Entry and exit criteria are also the same as
those of the P2MP transport paths in RFC6371 [3]. However, in a P2MP
transport path, all the leaf MEPs that detect a defect must be
indentified and differentiated from a normal leaf MEP(s), which does
not detect a defect.
Configuration is specified in Section 5.1.3 of RFC6371[3]. The
following configuration information must be configured: MEG-ID, MEP-
ID, list of the other MEPs in the MEG that are different between the
root MEP and leaf MEP, PHB for E-LSP and transmission rate.
Koike, et al. Expires May 8, 2013 [Page 8]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
Consequent actions of a unidirectional P2MP transport path are also
covered in Section 5.1.2 of RFC6371 [3]. Operators should be able to
enable/disable each consequent action.
All MEPs inside a MEG need to be configured and retain the
information when a proactive OAM function is enabled, as described in
Section 5.1.3 of RFC6371[3]. If there is no RP-HE, it is premised
that the EMS/NMS exists. Therefore, the above parameters are
statically configured.
3.2.2. Remote Defect Indication
This OAM function is not available on a P2MP transport path when
return paths do not exist. This OAM function can be implemented only
in RP-HE. However, the return path is out of the scope of MPLS-TP
requirements.
3.2.3. Alarm Reporting
FFS
3.2.4. Lock Reporting
For further study(FFS)
3.2.5. Packet Loss Measurement
FFS
3.2.6. Packet Delay Measurement
FFS
3.2.7. Client Failure Indication
FFS
3.3. OAM functions for on-demand monitoring
3.3.1. Connectivity verification
The connectivity verification function enables one or more leaf MEPs
on a P2MP transport path to monitor the connectivity of OAM packets
Koike, et al. Expires May 8, 2013 [Page 9]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
from a specific root MEP and detect an unexpected connectivity defect
between two MEGs (two P2MP transport paths)
1. Connectivity verification functions MUST be supported when return
paths in a unidirectional P2MP transport path do not exist.
As described in RFC6371 [3], CC-V OAM packets are used for a P2MP
transport path. Defect detection mechanisms in P2MP transport paths
are the same as those of the P2MP transport path specified in section
5.1 of RFC6371. That is, loss of continuity defect, mis-connectivity
defect, period mis-configuration defect and unexpected encapsulation
defect. Entry and exit criteria are also the same as those of the
P2MP transport path in RFC6371 [3]. Moreover, consequent actions of a
unidirectional P2MP transport path are also covered in Section 5.1.2
of the RFC [3]
Regarding configuration consideration, the following additional
requirements on a unidirectional P2MP transport path when a return
path does not exist.
3.3.2. Packet loss measurement
FFS
3.3.3. Diagnostic tests
Diagnostic test functions MUST be supported when a return path in
a unidirectional P2MP transport path doesn't exist.
Other requirements are ffs.
3.3.4. Route Tracing
Route tracing function MUST be supported when a return path in a
unidirectional P2MP transport path doesn't exist.
Other requirements are ffs.
3.3.5. Packet delay measurement
FFS
Koike, et al. Expires May 8, 2013 [Page 10]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
3.4. OAM functions for administration control
3.4.1. Lock Instruct
FFS.
4. P2MP Recovery
FFS
5. Security Considerations
This document does not raise any particular security considerations.
6. IANA Considerations
There are no IANA actions required by this draft.
7. References
7.1. Normative References
[1] Niven-Jenkins, B., et all, "equirements of an MPLS Transport
Profile" RFC5654, September 2009
[2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC5860, May 2010
[3] Busi, I., Dave, A. , "Operations, Administration and
Maintenance Framework for MPLS-based Transport Networks ",
RFC6371, September 2011
[4] Frost, Dan.,et all, "Framework for Point-to-Multipoint MPLS
in Transport Networks" draft-fbb-mpls-tp-p2mp-framework-05,
August 2012
7.2. Informative References
None
8. Acknowledgments
The author would like to thank all members (including MPLS-TP
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
Koike, et al. Expires May 8, 2013 [Page 11]
Internet-Draft MPLS-TP p2mp OAM framework November 2012
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
Takafumi Hamano
NTT
hamano.takafumi@lab.ntt.co.jp
Masatoshi Namiki
NTT
namiki.masatoshi@lab.ntt.co.jp
Yoshinori Koike
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Koike, et al. Expires May 8, 2013 [Page 12]