draft-ietf-mpls-tp-linear-protection-00.txt   draft-ietf-mpls-tp-linear-protection-01.txt 
Network Working Group S. Bryant, Ed. Network Working Group S. Bryant, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track N. Sprecher, Ed. Intended status: Standards Track N. Sprecher, Ed.
Expires: August 8, 2010 Nokia Siemens Networks Expires: September 8, 2010 Nokia Siemens Networks
H. van Helvoort, Ed. H. van Helvoort, Ed.
Huawei Huawei
A. Fulignoli, Ed. A. Fulignoli, Ed.
Ericsson Ericsson
Y. Weingarten Y. Weingarten
Nokia Siemens Networks Nokia Siemens Networks
February 4, 2010 March 7, 2010
MPLS-TP Linear Protection MPLS-TP Linear Protection
draft-ietf-mpls-tp-linear-protection-00.txt draft-ietf-mpls-tp-linear-protection-01.txt
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF
and ITU-T includes requirements documents and framework documents. and ITU-T includes requirements documents and framework documents.
The framework documents define the basic architecture that is needed The framework documents define the basic architecture that is needed
in order to support various aspects of the required behavior. This in order to support various aspects of the required behavior. This
document addresses the functionality described in the MPLS-TP document addresses the functionality described in the MPLS-TP
Survivability Framework document and defines a protocol that may be Survivability Framework document and defines a protocol that may be
used to fulfill the function of the Protection State Coordination for used to fulfill the function of the Protection State Coordination for
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 42 skipping to change at page 6, line 42
3. Protection switching logic 3. Protection switching logic
3.1. Protection switching trigger mechanisms 3.1. Protection switching trigger mechanisms
The protection switching should be initiated in reaction to any of The protection switching should be initiated in reaction to any of
the following triggers: the following triggers:
o Server layer indication - if the MPLS-TP server layer detects a o Server layer indication - if the MPLS-TP server layer detects a
failure within its own layer, or due to a failure of its server failure within its own layer, or due to a failure of its server
layer (e.g. the physical layer) notifies the MPLS-TP layer that a layer (e.g. the physical layer) notifies the MPLS-TP layer that a
failure has been detected. failure has been detected. It should be noted that this trigger
will be controlled by a holdoff-timer that should be configured to
allow the server layer to apply any protection procedures that may
be relevant.
o OAM signalling - if, for example, OAM continuity and connectivity o OAM signalling - if, for example, OAM continuity and connectivity
verification tools detect that there is a loss of continuity or verification tools detect that there is a loss of continuity or
mis-connectivity or performance monitoring indicates a degradation mis-connectivity or performance monitoring indicates a degradation
of the utility of the working path for the current transport path. of the utility of the working path for the current transport path.
In cases of signal degradation, switching to the recovery path In cases of signal degradation, switching to the recovery path
SHOULD only be activated if the recovery path can guarantee better SHOULD only be activated if the recovery path can guarantee better
conditions than the degraded working path. conditions than the degraded working path.
o Control plane - if there is a control plane active in the network o Control plane - if there is a control plane active in the network
skipping to change at page 10, line 38 skipping to change at page 10, line 38
Figure 2: Format of PSC packet with a GACH header Figure 2: Format of PSC packet with a GACH header
Where: Where:
o MPLS-TP PSC Channel Code is the GACH channel number assigned to o MPLS-TP PSC Channel Code is the GACH channel number assigned to
the PSC = TBD the PSC = TBD
o The ACH TLV Header is described in [RFC5586] o The ACH TLV Header is described in [RFC5586]
o The use of the Addressing TLV are for further study o The use of an Addressing TLV is for further study
o The following figure shows the format of the PSC Control message o Figure 3 shows the format of the PSC Control message that is the
that is the payload for the PSC packet. payload for the PSC packet.
Editor's note: There is a suggestion that this format should be Editor's note: There is a suggestion that this format should be
aligned with the format used by G.8031/G.8131/Y.1731 in ITU. The aligned with the format used by G.8031/G.8131/Y.1731 in ITU. The
argument being that this would make it easier to pass review from ITU argument being that this would make it easier to pass review from ITU
and allow easier transfer of technology. and allow easier transfer of technology.
The counter-argument is that the ITU format is based upon an attempt The counter-argument is that the ITU format is based upon an attempt
to find a common format for different functionality and therefore to find a common format for different functionality and therefore
involves different fields that are not necessary for the protection involves different fields that are not necessary for the protection
switching. Defining a new dedicated format would make for a simpler switching. Defining a new dedicated format would make for a simpler
and more intuitive protocol. End of editor's note. and more intuitive protocol. End of editor's note.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request| PT| FPath | Path | Reserved | |Ver|Request| PT| FPath | Path | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the PSC control packet Figure 3: Format of the PSC control packet
Where: Where:
o Ver: is the version of the protocol, for this version the value o Ver: is the version of the protocol, for this version the value
SHOULD be 0. SHOULD be 0.
o Request: this field indicates the specific PSC request that is o Request: this field indicates the specific PSC request that is
skipping to change at page 12, line 8 skipping to change at page 12, line 8
o (0101) Signal degrade o (0101) Signal degrade
o (0100) Manual switch o (0100) Manual switch
o (0011) Wait to restore o (0011) Wait to restore
o (0010) Do not revert (DNR) o (0010) Do not revert (DNR)
o (0000) No request o (0000) No request
See section 6.3 for a description of the operation of the different See section 4.3 for a description of the operation of the different
requests. requests.
4.2.2. Protection Type (PT) 4.2.2. Protection Type (PT)
The PT field indicates the currently configured protection The PT field indicates the currently configured protection
architecture type, this should be validated to be consistent for both architecture type, this should be validated to be consistent for both
ends of the protected domain. If an inconsistency is detected then ends of the protected domain. If an inconsistency is detected then
an alarm should be raised. The following are the possible values: an alarm should be raised. The following are the possible values:
o 11: 1+1 bidirectional switching o 11: 1+1 bidirectional switching
o 10: 1:1 bidirectional switching o 10: 1:1 bidirectional switching
o 01: 1+1 unidirectional switching o 01: 1+1 unidirectional switching
o 00: 1:1 unidirectional switching o 00: 1:1 unidirectional switching
4.2.3. Path fault identifier (FPath) 4.2.3. Path fault identifier (FPath)
The Fpath field of the PSC control SHALL be used only in a Signal The Fpath field of the PSC control SHALL be used only in a Signal
fault (0101) or Signal degrade (0100) control packet. Its value fault (0110) or Signal degrade (0101) control packet. Its value
indicates on which path the signal anomaly was detected. The indicates on which path the signal anomaly was detected. The
following are the possible values: following are the possible values:
o 0: indicates that the fault condition is on the Recovery path o 0: indicates that the fault condition is on the Recovery path
o 1: indicates that the fault condition is on the Working path o 1: indicates that the fault condition is on the Working path
o 2-255: for future extensions o 2-255: for future extensions
4.2.4. Active path indicator (Path) 4.2.4. Active path indicator (Path)
skipping to change at page 15, line 26 skipping to change at page 15, line 26
4.3.3. Lockout of Protection 4.3.3. Lockout of Protection
If one of the LSRs (for example, LSR-A) receives a management command If one of the LSRs (for example, LSR-A) receives a management command
indicating that the protection is disabled, then it SHOULD indicate indicating that the protection is disabled, then it SHOULD indicate
this to the far-end LSR (LSR-Z in this example) that it is not this to the far-end LSR (LSR-Z in this example) that it is not
possible to use the recovery path. The following actions MUST be possible to use the recovery path. The following actions MUST be
taken: taken:
o Transmit a PCS control packet, using GACH, with the Request code o Transmit a PCS control packet, using GACH, with the Request code
set to Lockout of protection (1110), the Fpath set to 0, and the set to Lockout of protection (1110), the Fpath may be set to 0,
Path set to 0. and the Path set to 0.
o All normal traffic packets should be transmitted on the working o All normal traffic packets should be transmitted on the working
path only. path only.
o Verify that the far-end LSR (for example LSR-Z) is forwarding the o Verify that the far-end LSR (for example LSR-Z) is forwarding the
data packets on the working path. Raise alarm in case of data packets on the working path. Raise alarm in case of
mismatch. mismatch.
o The PSC control logic should go into Unavailable state. o The PSC control logic should go into Unavailable state.
skipping to change at page 16, line 45 skipping to change at page 16, line 45
If the management system indicated to one of the LSRs (for example If the management system indicated to one of the LSRs (for example
LSR-A) that a switch is necessary, e.g. either a Forced Switch or a LSR-A) that a switch is necessary, e.g. either a Forced Switch or a
Manual Switch, then the LSR SHOULD switch the traffic to the recovery Manual Switch, then the LSR SHOULD switch the traffic to the recovery
path and perform the following actions: path and perform the following actions:
o Switch all data traffic to the recovery path only. o Switch all data traffic to the recovery path only.
o Transmit a PCS control packet, using GACH, with the appropriate o Transmit a PCS control packet, using GACH, with the appropriate
Request code (either Manual switch or Forced switch), the Fpath Request code (either Manual switch or Forced switch), the Fpath
set to 0, to indicate that the fault/degrade was detected on the may be set to 1, to indicate that there is an event that affects
working path, and the Path set to 1, indicating that traffic is the working path, and the Path set to 1, indicating that traffic
now being forwarded on the recovery path. is now being forwarded on the recovery path.
o Verify that LSR-Z replies with a PCS control packet indicating o Verify that LSR-Z replies with a PCS control packet indicating
that it has switched to the recovery path. If this is not that it has switched to the recovery path. If this is not
received after 2 PSC cycles then send an alarm to the management received after 2 PSC cycles then send an alarm to the management
system. system.
When the far-end LSR (in this example LSR-Z) receives the PCS packet When the far-end LSR (in this example LSR-Z) receives the PCS packet
informing it that other LSR (LSR-A) has switched, it SHOULD perform informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions: the following actions:
o Check priority of the request o Check priority of the request
o Switch all normal traffic addressed to LSR-A to the recovery path o Switch all normal traffic addressed to LSR-A to the recovery path
only. only.
o Begin transmission of a PCS control packet, using GACH, with the o Begin transmission of a PCS control packet, using GACH, with the
appropriate Request code (either Manual switch of Forced switch), appropriate Request code (either Manual switch of Forced switch),
the Fpath set to 1, to indicate that the fault/degrade was the Fpath may be set to 1, to indicate that there is an event that
detected on the working path, and the Path set to 1, indicating affects the working path, and the Path set to 1, indicating that
that traffic is now being forwarded on the recovery path. traffic is now being forwarded on the recovery path.
4.3.5.1. Clearing operator commands 4.3.5.1. Clearing operator commands
The operator may clear the switching condition by issuing a Clear The operator may clear the switching condition by issuing a Clear
request. This command will cause immediate recovery from the switch request. This command will cause immediate recovery from the switch
that was initiated by any of the previous operator commands, i.e. that was initiated by any of the previous operator commands, i.e.
Forced Switch or Manual Switch. In addition, a Clear command after a Forced Switch or Manual Switch. In addition, a Clear command after a
Lockout Protection command should clear the Unavailable state and Lockout Protection command should clear the Unavailable state and
return the protection domain to the normal state. return the protection domain to the normal state.
 End of changes. 13 change blocks. 
19 lines changed or deleted 22 lines changed or added

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