TOC 
Network Working GroupS. Bryant, Ed.
Internet-DraftCisco
Intended status: Standards TrackN. Sprecher, Ed.
Expires: September 8, 2010Nokia Siemens Networks
 H. van Helvoort, Ed.
 Huawei
 A. Fulignoli, Ed.
 Ericsson
 Y. Weingarten
 Nokia Siemens Networks
 March 07, 2010


MPLS-TP Linear Protection
draft-ietf-mpls-tp-linear-protection-01.txt

Abstract

The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF and ITU-T includes requirements documents and framework documents. The framework documents define the basic architecture that is needed in order to support various aspects of the required behavior. This document addresses the functionality described in the MPLS-TP Survivability Framework document and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document.

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 as defined by the ITU-T.

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 8, 2010.

Copyright Notice

Copyright (c) 2010 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. 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 BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.



Table of Contents

1.  Introduction
    1.1.  Contributing authors
2.  Conventions used in this document
    2.1.  Acronyms
    2.2.  Definitions and Terminology
3.  Protection switching logic
    3.1.  Protection switching trigger mechanisms
    3.2.  Protection switching control logical architecture
        3.2.1.  PSC Status Module
4.  Protection state coordination (PSC) protocol
    4.1.  Transmission and acceptance of PSC control packets
    4.2.  Protocol format
        4.2.1.  PSC Requests
        4.2.2.  Protection Type (PT)
        4.2.3.  Path fault identifier (FPath)
        4.2.4.  Active path indicator (Path)
    4.3.  Principles of Operation
        4.3.1.  PSC States
        4.3.2.  Failure or Degraded condition (Working path)
        4.3.3.  Lockout of Protection
        4.3.4.  Failure or Degraded condition (Recovery path)
        4.3.5.  Operator Controlled Switching
        4.3.6.  Recovery from switching
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction

As noted in the architecture for Multi-Protocol Label Switching Transport Profile (MPLS-TP) [TPFwk] (Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks,” July 2009.), the overall architecture framework for MPLS-TP is based on a profile of the MPLS and Pseudowire (PW) procedures as specified for the MPLS and (MS-)PW architectures defined in [RFC3031] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” Jan 2001.), [RFC3985] (Bryant, S. and P. Pate, “Pseudowire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [RFC5085] (Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.). One of the basic survivability functions, pointed out by the Survivability Framework document [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), is that of simple and rapid protection switching mechanisms for Label Switched Paths (LSP) and Pseudo-wires (PW).

Protection switching is a fully allocated survivability mechanism. It is fully allocated in the sense that the route and bandwidth of the recovery path is reserved for a selected working path or set of working paths. It provides a fast and simple survivability mechanism, that allows the network operator to easily grasp the active state of the network, compared to other survivability mechanisms.

As specified in the Survivability Framework document [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), protection switching is applied to a protected domain. For the purposes of this document, we define the protected domain of a P2P LSP as consisting of two Label Switching Routers (LSR) and the transport paths that connect them. For a P2MP LSP the protection domain includes the root (or source) LSR, the destination (or sink) LSRs, and the transport paths that connect them.

In 1+1 unidirectional architecture as presented in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), a recovery transport path is dedicated to each working transport path. Normal traffic is bridged (as defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.))and fed to both the working and the recovery transport entities by a permanent bridge at the source of the protection domain. The sink of the protection domain selects which of the working or recovery entities to receive the traffic from, based on a predetermined criteria, e.g. server defect indication. When used for bidirectional switching the 1+1 protection architecture must also support a Protection State Coordination (PSC) protocol. This protocol is used to help synchronize the decisions of both ends of the protection domain in selecting the proper traffic flow.

In the 1:1 architecture, a recovery transport path is dedicated to the working transport path of a single service. However, the normal traffic is transmitted only once, on either the working or the recovery path, by using a selector bridge at the source of the protection domain. A selector at the sink of the protection domain then selects the path that carries the normal traffic. Since the source and sink need to be coordinated to ensure that the selector bridge at both ends select the same path, this architecture must support a PSC protocol.

The 1:n protection architecture extends this last architecture by sharing the recovery path amongst n services. Again, the recovery path is fully allocated and disjoint from any of the n working transport paths that it is being used to protect. The normal data traffic for each service is transmitted only once, either on the normal working path for that service or, in cases that trigger protection switching (as defined in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.)), may be sent on the recovery path. It should be noted that in cases where multiple working path services have triggered protection switching that some services, dependent upon their Service Level Agreement (SLA), may not be transmitted as a result of limited resources on the recovery path. In this architecture there is a need for coordination of the protection switching, and in addition there is need for resource allocation negotiation. Due to the added complexity of this architecture, the procedures for this will be delayed to a different document and further study.

As was pointed out in the Survivability Framework [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) and highlighted above, there is a need for coordination between the end-points of the protection domain when employing bidirectional protection schemes. This is especially true when there is a need to maintain traffic over a co-routed bidirectional LSP. This document presents a protocol and a set of procedures for activating this coordination within the protection domain.



 TOC 

1.1.  Contributing authors

Hao Long (Huawei)



 TOC 

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.1.  Acronyms

This draft uses the following acronyms:

DNR Do not revert
FS Forced Switch
GACH Generic Associated Channel Header
LSR Label Switching Router
MPLS-TP Transport Profile for MPLS
MS Manual Switch
P2P Point-to-point
P2MP Point-to-multipoint
PDU Packet Data Unit
PSC Protection State Coordination Protocol
PST Path Segment Tunnel
SD Signal Degrade
SF Signal Fail
SLA Service Level Agreement
WTR Wait-to-Restore



 TOC 

2.2.  Definitions and Terminology

The terminology used in this document is based on the terminology defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.) and further adapted for MPLS-TP in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). In addition, we use the term LSR to refer to a MPLS-TP Network Element, whether it is a LSR, LER, T-PE, or S-PE.



 TOC 

3.  Protection switching logic



 TOC 

3.1.  Protection switching trigger mechanisms

The protection switching should be initiated in reaction to any of the following triggers:



 TOC 

3.2.  Protection switching control logical architecture

Protection switching processes the triggers described above together with the inputs received from the far-end LSR. These inputs cause the LSR to take certain actions, e.g. switching the Selector Bridge to select the working or recovery path, and to transmit different protocol messages.



+-------------+ Operator Command       Local PSC      +-----------+
|  External   |-----------------+   +-----------------| PSC Status|
|  Interface  |                 |   |   request   +---|   Module  |
+-------------+                 |   |             |   +-----------+
                                V   V             V Prot. Stat. ^
+----------+ Local OAM  +---------------+Highest +------------+ |
|   OAM    |----------->| Local Request |------->|  PSC Mess. | |
|  Module  |  request   |    logic      |local R.| Generator  | |
+----------+   +------->+---------------+        +------------+ |
+----------+   |                      |                 |       |
| Svr/CP   |---+         Highest local|request          |       |
+----------+                          V                 V       |
+-------------+             +-----------------+    PSC Message  |
| Remote Req. | Remote PSC  |  global Request |                 |
|  Receiver   |------------>|      logic      |                 |
+-------------+   Request   +-----------------+                 |
       ^                             |                          |
       |       Highest global request|                          |
       |                             V                          |
       |                    +-----------------+   PSC status    |
Remote PSC message          |    PSC Process  |-----------------+
                            |       logic     |--------> Action
                            |                 |
                            +-----------------+

 Figure 1: Protection switching control logic 

Figure 1 (Protection switching control logic) describes the logical architecture of the protection switching control. The Local Request logic unit accepts the triggers from the OAM, external operator commands, and from the local control plane (when present) and determines the highest priority request. This high-priority request is passed to both the PSC Message generator, that will generate the appropriate protocol message to be sent to the far-end LSR, and the Global Request logic, that will cross-check this local request with the information received from the far-LSR. The Global Request logic then processes these two PSC requests that determines the highest priority request that is passed to the PSC Process logic. The PSC Process logic uses this input to determine what actions need to be taken, e.g. switching the Selector Bridge, and the current status of the protection domain.



 TOC 

3.2.1.  PSC Status Module

The PSC Control Logic must retain the status of the protection domain. The possible different states indicate the current status of the protection environment, and can be in one of three states:

This state may affect the actions taken by the control logic, and therefore, the PSC Status Module transfers the current status to the Local Request Logic.

See section 4.3.1 for details on what actions are affected by the PSC state.



 TOC 

4.  Protection state coordination (PSC) protocol

Bidirectional protection switching, as well as unidirectional 1:1 protection, requires coordination between the two end-points in determining which of the two possible paths, the working or recovery path, is transmitting the data traffic in any given situation. When protection switching is triggered as described in section 3.1, the end-points must inform each other of the switch-over from one path to the other in a coordinated fashion.

There are different possibilities for the type of coordinating protocol. One possibility is a two-phased coordination in which the MEP that is initiating the protection switching sends a protocol message indicating the switch but the actual switch-over is performed only after receiving an 'Ack' from the far-end MEP. The other possibility is a single-phased coordination, in which the initiating MEP switches over to the alternate path and informs the far-end MEP of the switch, and the far-end MEP must complete the switch-over.

In the following sub-sections we describe the protocol messages that should be used between the two end-points of the protection domain.

For the sake of simplicity of the protocol, this protocol is based on the single-phase approach described above.



 TOC 

4.1.  Transmission and acceptance of PSC control packets

The PSC control packets should be transmitted over the recovery path only. This allows the transmission of the messages without affecting the normal traffic in the most prevalent case, i.e. the idle state. In addition, limiting the transmission to a single path avoids possible conflicts and race conditions that could develop if the PSC messages were sent on both paths.

Any new PSC control packet must be transmitted immediately when a change in the transmitted status occurs.

When the PSC information is changed, three PSC packets should be transmitted as quickly as possible, so that fast protection switching would be possible. Transmission of three rapid packets allows for fast protection switching even if one or two PSC packets are lost or corrupted. The frequency of the first three packets and the separate frequency of the continual transmission is configurable by the operator. For protection switching within 50ms, the default interval of the first three PSC signals should be no larger than 3.3ms. PSC packets after the first three should be transmitted with an interval of 5 seconds.

If no valid PSC specific information is received, the last valid received information remains applicable. In the event a signal fail condition is detected on the recovery path, the received PSC specific information should be evaluated.



 TOC 

4.2.  Protocol format

The protocol messages SHALL be sent over the GACH as described in [RFC5586] (Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” May 2009.). There is a single channel type for the set of PSC messages, each message will be identified by the first field of the ACH payload as described below. PSC messages SHOULD support addressing by use of the method described in [RFC5586] (Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” May 2009.). The following figure shows the format for the full PSC message.



    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 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|   MPLS-TP PSC Channel Code    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ACH TLV Header                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Addressing TLV                             +
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    PSC Control Packet                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 2: Format of PSC packet with a GACH header 

Where:

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 argument being that this would make it easier to pass review from ITU and allow easier transfer of technology.

The counter-argument is that the ITU format is based upon an attempt to find a common format for different functionality and therefore involves different fields that are not necessary for the protection switching. Defining a new dedicated format would make for a simpler and more intuitive protocol. End of editor's note.



   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|Request| PT|   FPath       |     Path      |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 3: Format of the PSC control packet 

Where:



 TOC 

4.2.1.  PSC Requests

The Protection State Coordination (PSC) protocol SHALL support the following request types, in order of priority from highest to lowest:

See section 4.3 for a description of the operation of the different requests.



 TOC 

4.2.2.  Protection Type (PT)

The PT field indicates the currently configured protection architecture type, this should be validated to be consistent for both ends of the protected domain. If an inconsistency is detected then an alarm should be raised. The following are the possible values:



 TOC 

4.2.3.  Path fault identifier (FPath)

The Fpath field of the PSC control SHALL be used only in a Signal fault (0110) or Signal degrade (0101) control packet. Its value indicates on which path the signal anomaly was detected. The following are the possible values:



 TOC 

4.2.4.  Active path indicator (Path)

The Path field of the PSC control SHALL be used to indicate which path the source MEP is currently using for data transmission. The MEP should compare the value of this bit with the path that is locally selected for data transmission to verify that there is no inconsistency between the two end-points of the protected domain. If an inconsistency is detected then an alarm should be raised. The following are the possible values:



 TOC 

4.3.  Principles of Operation

In all of the following sub-sections, assume a protected domain between LSR-A and LSR-Z, using paths W (working) and R (recovery) as shown in figure 4.



              +-----+ //=======================\\ +-----+
              |LSR-A|//     Working Path        \\|LSR-Z|
              |    /|                             |\    |
              |  ?< |                             | >?  |
              |    \|\\     Recovery Path       //|/    |
              +-----+ \\=======================// +-----+

                  |--------Protected Domain---------|

 Figure 4: Protected domain 



 TOC 

4.3.1.  PSC States



 TOC 

4.3.1.1.  Normal State

When the protected domain has no special condition in effect, the ingress LSR SHOULD forward the user data along the working path, and, in the case of 1+1 protection, the Permanent Bridge will bridge the data to the recovery path as well. The receiving LSR SHOULD read the data from the working path.

The ingress LSR MAY transmit a No Request PSC packet with the Path field set to 0 indicating that the normal data traffic should be read from the working path.



 TOC 

4.3.1.2.  Protecting State

When the protection mechanism has been triggered and the protected domain has performed a protection switch, the domain is in the protecting state. In this state the normal data traffic is transmitted and received on the recovery path.

If the protection domain is currently in a protecting state, then the LSRs SHOULD NOT accept a Manual Switch request.

If the protection domain is currently in a protecting state, and a Forced Switch is requested then the normal traffic SHALL continue to be transmitted on the recovery path even if the original protection trigger is cleared, and the Forced Switch condition will be signalled by the PSC messages.



 TOC 

4.3.1.3.  Unavailable State

When the recovery path is unavailable – either as a result of a Lockout operator command (see section 4.3.3), or as a result of a SF or SD detected on the recovery path (see section 4.3.4) – then the protection domain is in the unavailable state. In this state, the normal traffic is transmitted and received on the working path.

While in unavailable state any event that would trigger a protection switching SHOULD be ignored with the following exception – If a Signal Degrade request is received, then protection switching will be activated only if the recovery path can guarantee a better signal than the working path.

The protection domain will exit the unavailable state and revert to the normal state when, either the operator clears the Lockout command or the recovery path recovers from the signal fault or degraded situation. Both ends will resume sending the PCS packets over the recovery path, as a result of this recovery.



 TOC 

4.3.2.  Failure or Degraded condition (Working path)

If one of the LSRs (for example, LSR-A) detects a failure condition or a serious degradation condition on the working path that warrants invoking protection switching, then it SHOULD take the following actions:

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 the following actions:



 TOC 

4.3.3.  Lockout of Protection

If one of the LSRs (for example, LSR-A) receives a management command 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 possible to use the recovery path. The following actions MUST be taken:

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 the following actions:



 TOC 

4.3.4.  Failure or Degraded condition (Recovery path)

If one of the LSRs (for example, LSR-A) detects a failure condition or a serious degradation condition on the recovery path, then it SHOULD take the following actions:

When the far-end LSR (in this example LSR-Z) receives the PCS packet informing it that other LSR (LSR-A) has become Unavailable, it SHOULD perform the following actions:



 TOC 

4.3.5.  Operator Controlled Switching

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 Manual Switch, then the LSR SHOULD switch the traffic to the recovery path and perform the following actions:

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 the following actions:



 TOC 

4.3.5.1.  Clearing operator commands

The operator may clear the switching condition by issuing a Clear request. This command will cause immediate recovery from the switch that was initiated by any of the previous operator commands, i.e. Forced Switch or Manual Switch. In addition, a Clear command after a Lockout Protection command should clear the Unavailable state and return the protection domain to the normal state.

If the Clear request is issued in the absence of a Manual Switch, Forced Switch, or Lockout protection, then it SHALL be ignored. In the presence of any of these commands, the Clear request SHALL clear the state affected by the operator command.



 TOC 

4.3.6.  Recovery from switching

When the condition that triggered the protection switching clears, e.g. the cause of the failure condition has been corrected, or the operator clears a Manual Switch, then the protection domain SHOULD follow the following procedures:



 TOC 

4.3.6.1.  Wait-to-restore timer

In revertive mode, in order to prevent frequent activation of protection switching due to an intermittent defect, the working transport path must become stable and fault-free before reverting to the normal condition. In order to verify that this is the case a fixed period of time must elapse before the normal traffic uses the working transport path. This period, called the Wait-to-restore (WTR) period, should be configurable by the operator in 1-minute intervals within the range 1-12 minutes. The default value is 5 minutes.

During this period, if a failure condition is detected on the working transport path, then the WTR timer is cleared and the normal traffic SHALL continue to be transported over the recovery transport path. If the WTR timer expires without being pre-empted by a failure, then the traffic SHOULD be returned to use the working transport path (as above).



 TOC 

5.  IANA Considerations

To be added in future version.



 TOC 

6.  Security Considerations

To be added in future version.



 TOC 

7.  Acknowledgements

The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997.


 TOC 

8.2. Informative References

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” RFC 3031, Jan 2001.
[RFC3985] Bryant, S. and P. Pate, “Pseudowire Emulation Edge-to-Edge (PWE3) Architecture,” RFC 3985, March 2005 (TXT).
[RFC5085] Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” RFC 5085, December 2007 (TXT).
[TPFwk] Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks,” ID draft-ietf-mpls-tp-framework-06.txt, July 2009.
[RFC5586] Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” RFC 5586, May 2009.
[RFC4427] Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” RFC 4427, Mar 2006.
[SurvivFwk] Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” ID draft-ietf-mpls-tp-survive-fwk-02.txt, Feb 2009.
[RFC4872] Lang, J., Papadimitriou, D., and Y. Rekhter, “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery,” RFC 4872, May 2007.
[RFC3945] Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” RFC 3945, Oct 2004.


 TOC 

Authors' Addresses

  Stewart Bryant (editor)
  Cisco
  United Kingdom
Email:  stbryant@cisco.com
  
  Nurit Sprecher (editor)
  Nokia Siemens Networks
  3 Hanagar St. Neve Ne'eman B
  Hod Hasharon, 45241
  Israel
Email:  nurit.sprecher@nsn.com
  
  Huub van Helvoort (editor)
  Huawei
  Kolkgriend 38, 1356 BC Almere
  Netherlands
Phone:  +31 36 5316076
Email:  hhelvoort@huawei.com
  
  Annamaria Fulignoli (editor)
  Ericsson
  Italy
Phone: 
Email:  annamaria.fulignoli@ericsson.com
  
  Yaacov Weingarten
  Nokia Siemens Networks
  3 Hanagar St. Neve Ne'eman B
  Hod Hasharon, 45241
  Israel
Phone:  +972-9-775 1827
Email:  yaacov.weingarten@nsn.com