Skip to main content

MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators
RFC 7271

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    mpls mailing list <>,
    mpls chair <>
Subject: Protocol Action: 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators' to Proposed Standard (draft-ietf-mpls-tp-psc-itu-04.txt)

The IESG has approved the following document:
- 'MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
   Operational Expectations of SDH, OTN and Ethernet Transport Network
  (draft-ietf-mpls-tp-psc-itu-04.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

  This document describes alternate mechanisms to perform some of the
  MPLS-TP  linear protection sub-functions defined in RFC 6378. It also defines
  some additional mechanisms.   The purpose of these mechanisms is to closely
  model the behavior of linear protection seen in other transport networks.

  This document also introduces capabilities and modes for linear protection.  
  A capability is an individual behavior, and a mode is a particular combination 
  of capabilities.  Two modes are defined PSC mode and  APS mode.

  The document describes the behavior of the PSC protocol including
  when all the capabilities of the APS mode are enabled. The document
  describes priority logic and the protocol state machine.

  The document updates RFC 6378 in that the capability advertisement
  method defined here is an addition to that document.

Working Group Summary

  This document has a rather long history. It is intended to match the 
  operational practices and methods that have been used by transport 
  network operators prior to the introduction of MPLS. When RFC 6378 was
  progressed it was decided that backwards compatibility with deployed MPLS 
  networks was the priority. 

  Later the discussion on meeting the requirements from transport network
  operators re-emerged and it was decided that the solution should be based
  on RFC 6378. To that end RFC 6378 had to be slightly extended and
  modified. There were 5 capabilities missing in RFC 6378, these were the
  extensions.  There were also cases where relative priority between different
  actions need to be changed, these were the modifications.

  The first approach were to write a single document for each capability (at the
  time it was thought that the capabilities might be activated independently), 
  The discussion in the working group however converged on putting all the
  capabilities in one document.

  The first MPLS Review Team review and the discussion in the working clearly
  indicated a wish to make the merged document a working group document, so
  the chairs initiated a second MPLS Review Team review and took the 
  decision to make it a working group document without running the normal WG
  adoption poll, instead evaluating the discussion on the mailing and their own
  The document has, nevertheless been well discussed within the working group.

  After that the document became a working group document there has been a
  good and open discussion on the mailing.

  It is the Shepherds opinion that the document is ready for publication.
Document Quality

  An implementation poll has been sent to the working group mailing
  list and the write-up will be updated if and when the information is available.

  There are strong indications of vendor interest.

  There is a long list of important reviewers, especially the MPLS Review Team
  reviewers that contributed the arguments that resulted in the current document
  structure and that also did a careful technical review.


  Loa Andersson is the document shepherd
  Adrian Farrel is the responsible AD

RFC Editor Note