draft-ietf-mpls-tp-oam-framework-03.txt   draft-ietf-mpls-tp-oam-framework-04.txt 
MPLS Working Group I. Busi (Ed) MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Intended status: Informational B. Niven-Jenkins (Ed) Intended status: Informational B. Niven-Jenkins (Ed)
BT BT
D. Allan (Ed) D. Allan (Ed)
Ericsson Ericsson
Expires: June 2010 December 3, 2009 Expires: June 2010 December 10, 2009
MPLS-TP OAM Framework MPLS-TP OAM Framework
draft-ietf-mpls-tp-oam-framework-03.txt draft-ietf-mpls-tp-oam-framework-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 10 skipping to change at page 3, line 10
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. capabilities and functionalities of a packet transport network.
Table of Contents Table of Contents
1. Introduction..................................................5 1. Introduction..................................................5
1.1. Contributing Authors.....................................5 1.1. Contributing Authors.....................................5
1.2. Editors Issues...........................................6 1.2. Editors Issues...........................................6
2. Conventions used in this document.............................8 2. Conventions used in this document.............................9
2.1. Terminology..............................................8 2.1. Terminology..............................................9
2.2. Definitions..............................................9 2.2. Definitions.............................................10
3. Functional Components........................................11 3. Functional Components........................................12
3.1. Maintenance Entity and Maintenance Entity Group.........12 3.1. Maintenance Entity and Maintenance Entity Group.........13
3.2. MEG End Points (MEPs)...................................15 3.2. MEG End Points (MEPs)...................................16
3.3. MEG Intermediate Points (MIPs)..........................18 3.3. MEG Intermediate Points (MIPs)..........................19
3.4. Server MEPs.............................................19 3.4. Server MEPs.............................................20
3.5. Path Segment Tunnels and Tandem Connection Monitoring...20 3.5. Path Segment Tunnels and Tandem Connection Monitoring...21
4. Reference Model..............................................20 4. Reference Model..............................................21
4.1. MPLS-TP Section Monitoring..............................22 4.1. MPLS-TP Section Monitoring..............................23
4.2. MPLS-TP LSP End-to-End Monitoring.......................23 4.2. MPLS-TP LSP End-to-End Monitoring.......................24
4.3. MPLS-TP LSP Path Segment Tunnel Monitoring..............24 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring..............25
4.4. MPLS-TP PW Monitoring...................................26 4.4. MPLS-TP PW Monitoring...................................27
4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring............26 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring............27
5. OAM Functions for proactive monitoring.......................27 5. OAM Functions for proactive monitoring.......................28
5.1. Continuity Check and Connectivity Verification..........28 5.1. Continuity Check and Connectivity Verification..........29
5.1.1. Defects identified by CC-V.........................29 5.1.1. Defects identified by CC-V.........................30
5.1.2. Consequent action..................................30 5.1.2. Consequent action..................................31
5.1.3. Configuration considerations.......................31 5.1.3. Configuration considerations.......................32
5.1.4. Applications for proactive CC-V....................32 5.1.4. Applications for proactive CC-V....................33
5.2. Remote Defect Indication................................33 5.2. Remote Defect Indication................................34
5.2.1. Configuration considerations.......................33 5.2.1. Configuration considerations.......................34
5.2.2. Applications for Remote Defect Indication..........34 5.2.2. Applications for Remote Defect Indication..........35
5.3. Alarm Reporting.........................................34 5.3. Alarm Reporting.........................................35
5.4. Lock Reporting..........................................35 5.4. Lock Reporting..........................................36
5.5. Packet Loss Monitoring..................................35 5.5. Packet Loss Monitoring..................................36
5.5.1. Configuration considerations.......................36 5.5.1. Configuration considerations.......................37
5.5.2. Applications for Packet Loss Monitoring............36 5.5.2. Applications for Packet Loss Monitoring............37
5.6. Client Signal Failure Indication........................37 5.6. Client Signal Failure Indication........................38
5.6.1. Configuration considerations.......................37 5.6.1. Configuration considerations.......................38
5.6.2. Applications for Client Signal Failure Indication..37 5.6.2. Applications for Client Signal Failure Indication..38
5.7. Delay Measurement.......................................38 5.7. Delay Measurement.......................................39
5.7.1. Configuration considerations.......................38 5.7.1. Configuration considerations.......................39
5.7.2. Applications for Delay Measurement.................39 5.7.2. Applications for Delay Measurement.................40
6. OAM Functions for on-demand monitoring.......................39 6. OAM Functions for on-demand monitoring.......................40
6.1. Connectivity Verification...............................39 6.1. Connectivity Verification...............................40
6.1.1. Configuration considerations.......................40 6.1.1. Configuration considerations.......................41
6.2. Packet Loss Monitoring..................................41 6.2. Packet Loss Monitoring..................................42
6.2.1. Configuration considerations.......................41 6.2.1. Configuration considerations.......................42
6.2.2. Applications for On-demand Packet Loss Monitoring..41 6.2.2. Applications for On-demand Packet Loss Monitoring..42
6.3. Diagnostic..............................................41 6.3. Diagnostic..............................................42
6.4. Route Tracing...........................................42 6.4. Route Tracing...........................................43
6.5. Delay Measurement.......................................43 6.5. Delay Measurement.......................................44
6.5.1. Configuration considerations.......................43 6.5.1. Configuration considerations.......................44
6.5.2. Applications for Delay Measurement.................44 6.5.2. Applications for Delay Measurement.................45
6.6. Lock Instruct...........................................44 6.6. Lock Instruct...........................................45
7. Security Considerations......................................44 7. Security Considerations......................................45
8. IANA Considerations..........................................44 8. IANA Considerations..........................................45
9. Acknowledgments..............................................45 9. Acknowledgments..............................................46
10. References..................................................46 10. References..................................................47
10.1. Normative References...................................46 10.1. Normative References...................................47
10.2. Informative References.................................46 10.2. Informative References.................................47
Editors' Note: Editors' Note:
This Informational Internet-Draft is aimed at achieving IETF This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF Consensus before publication as an RFC and will be subject to an IETF
Last Call. Last Call.
[RFC Editor, please remove this note before publication as an RFC and [RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.] RFC has IETF Consensus.]
skipping to change at page 8, line 9 skipping to change at page 8, line 9
slipping a PST under it ... slipping a PST under it ...
Action (Italo): check which requirements cannot be met if PW TCM Action (Italo): check which requirements cannot be met if PW TCM
between non-adjacent PEs cannot be supported and whether this is a between non-adjacent PEs cannot be supported and whether this is a
showstopper issue or not. showstopper issue or not.
Action (Italo): describe the PW TCM as an LSP and circulate the Action (Italo): describe the PW TCM as an LSP and circulate the
description to the mailing list for review. If needed, another call description to the mailing list for review. If needed, another call
will be setup to finalize the discussion. will be setup to finalize the discussion.
Action (Matthew, Italo): Develop a couple of diagrams showing how the
mechanism works for LSPs and PWs.
5) Concerns have been raised against the idea of having MIPs capable 5) Concerns have been raised against the idea of having MIPs capable
to generate spontaneous messages. AIS/Lock Indication packets are to generate spontaneous messages. AIS/Lock Indication packets are
generated by the adaptation functions. This point needs generated by the adaptation functions. This point needs
clarifying. clarifying.
Agreement (9 December):
AIS/Lock Indication are generate by a MIP node (to be define as a
node hosting a MIP) w/o saying that they are generated by a MIP.
The general framework will describe the mechanism for intermediate
nodes to insert packets and each specific framework document (e.g.,
OAM framework) will describe the usage of this capability on a case-
by-case basis. When you provision bw between two end-points you must
allow enough bw for any additional traffic, including traffic from
MEPs and MIPs.
OAM framework will describe that a MIP node may insert OAM packets
into a LSP and this will be described on a function-by-function
basis. It will also describe the functions that require a MIP to
generate OAM packets (e.g., on-demand CV).
6) Presence or absence of MIPs is a bizarre point. At least one MIP 6) Presence or absence of MIPs is a bizarre point. At least one MIP
in every node is addressed by TTL, and gaps in the enablement of in every node is addressed by TTL, and gaps in the enablement of
MIPs would produce spurious test results. A convention of "MIPs MIPs would produce spurious test results. A convention of "MIPs
exist at any node on a transport path that has a return path to a exist at any node on a transport path that has a return path to a
source MEP" would make sense vs. discussing manual source MEP" would make sense vs. discussing manual
enable/disable/configuration of MIPs. enable/disable/configuration of MIPs.
Note - the annotated text ("If the set of MIPs is actually sparse Note - the annotated text ("If the set of MIPs is actually sparse
(i.e. not every hop is a MIP), then it has to be intermediate nodes (i.e. not every hop is a MIP), then it has to be intermediate nodes
to do some operations") needs further clarification. to do some operations") needs further clarification.
Agreement (9 December):
All the intermediate nodes host MIP(s). Local policy allows them to
be enabled per function and per LSP. The local policy is controlled
by the management system, which may delegate it to the control plane.
7) Discussions in Hiroshima and subsequent calls have suggested use 7) Discussions in Hiroshima and subsequent calls have suggested use
of alternative return paths "if available", not all of which will of alternative return paths "if available", not all of which will
be GAL/GACH encapsulated? This point needs clarifying. be GAL/GACH encapsulated? This point needs clarifying.
Agreement (9 December):
When the return path is not an MPLS-TP path, the reply message does
not need to be GAL/ACH encapsulated.
The request message needs to carry sufficient information to allow
the target MIP/MEP to reply when a non MPLS-TP return path is used.
8) Data plane loopback 8) Data plane loopback
Action (17 November): check on the mailing list (both ITU-T and IETF Action (17 November): check on the mailing list (both ITU-T and IETF
to get inputs from both types of operators). to get inputs from both types of operators).
9) Review the draft to check that all the known implications related 9) Review the draft to check that all the known implications related
to the support of p2mp transport paths have been described. to the support of p2mp transport paths have been described.
This check will be done in the next version after the current open
points/comments have been resolved.
10)Given layering discussion in Hiroshima, it is not very clear 10)Given layering discussion in Hiroshima, it is not very clear
whether MPLS TP is a sub layer network within the MPLS layer whether MPLS TP is a sub layer network within the MPLS layer
network or a layer network by its own. This issue should be network or a layer network by its own.
resolved in the context of the MPLS TP Framework draft but has
impacts on this draft as well. This issue should be resolved in the context of the MPLS TP Framework
draft but has impacts on this draft as well.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
2.1. Terminology 2.1. Terminology
AC Attachment Circuit AC Attachment Circuit
skipping to change at page 17, line 30 skipping to change at page 18, line 30
Clarify that we need to provide enough bandwidth on the transport Clarify that we need to provide enough bandwidth on the transport
paths to support OAM traffic (throughout the framework document). paths to support OAM traffic (throughout the framework document).
From IETF point of view no distinction between MIPs and adaptation From IETF point of view no distinction between MIPs and adaptation
functions. functions.
Lou question about how triggered response OAM packets are sent by Lou question about how triggered response OAM packets are sent by
MIPs/MEPs. MIPs/MEPs.
Agreement (call 17 November): Agreement (call 9 December):
o bidirectional co-routed: MUST support and SHOULD use the o bidirectional co-routed: use the reverse path (thus checking
reverse path. It MAY use any other available return path if both the forward and backward directions of the transport
requested by the OAM message triggering the reply. Clarify path). Co-routed bidirectional transport paths can have a
that using the reverse path checks both forward and backward minimum bandwidth return path.
directions while other return paths check only the forward
direction.
o unidirectional p2p and p2mp: no ability to support triggered o unidirectional p2p and p2mp: no ability to support triggered
response OAM message unless other return paths are available response OAM message
o associated bidirectional: MEPs like co-routed; MIPs like Non MPLS-TP LSP/PW return path MAY be requested by the OAM message
unidirectional triggering the reply and the target MIP/MEP MAY attempt to reply
using the requested return path.
In this case, only the forward direction of the MPLS-TP transport
path is checked and the connectivity to the source MEP via the
requested return path is not guaranteed.
Agreement (call 17 November) to use as a working assumption the same Agreement (call 17 November) to use as a working assumption the same
MEP/MIP model in MS-PW OAM architecture. In order to validate this MEP/MIP model in MS-PW OAM architecture. In order to validate this
working assumption we need to understand how to describe the PW working assumption we need to understand how to describe the PW
Status information: this information is propagated on a hop-by-hop Status information: this information is propagated on a hop-by-hop
basis between adjacent PEs using LDP (dynamic PW segments) or ACH basis between adjacent PEs using LDP (dynamic PW segments) or ACH
Status PW (static PW segments).] Status PW (static PW segments).]
3.3. MEG Intermediate Points (MIPs) 3.3. MEG Intermediate Points (MIPs)
 End of changes. 13 change blocks. 
68 lines changed or deleted 109 lines changed or added

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