Skip to main content

Liaison statement
Recent IETF RFCs of Interest to SG15

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2011-02-09
From Group RTG
From Contact Adrian Farrel
To Group ITU-T-SG-15
To Contacts Greg Jones <greg.jones@itu.int>
Cc Adrian Farrel <adrian.farrel@huawei.com>
Stewart Bryant <stbryant@cisco.com>
The IETF Chair <chair@ietf.org>
Response Contact Adrian Farrel <adrian.fareel@huawei.com>
Technical Contact Adrian Farrel <adrian.fareel@huawei.com>
Purpose For information
Attachments (None)
Body
I would like to take this oportunity to inform SG15 of a number of IETF
RFCs that have been published since SG15 last met in plenary session and
which may be of interest to experts in SG15 and to the work that you do.

I hope this information will be useful to SG15 in its future work.

Adrian Farrel
IETF Routing Area Director

- - - - - - -

RFC 5862

Title

   Path Computation Clients (PCC) - Path Computation Element (PCE)
   Requirements for Point-to-Multipoint MPLS-TE

Abstract

   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   Extensions to the MPLS and GMPLS signaling and routing protocols have
   been made in support of point-to-multipoint (P2MP) Traffic Engineered
   (TE) Label Switched Paths (LSPs).  The use of PCE in MPLS networks is
   already established, and since P2MP TE LSP routes are sometimes
   complex to compute, it is likely that PCE will be used for P2MP LSPs.

   Generic requirements for a communication protocol between Path
   Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path
   Computation Element (PCE) Communication Protocol Generic
   Requirements".  This document complements the generic requirements
   and presents a detailed set of PCC-PCE communication protocol
   requirements for point-to-multipoint MPLS/GMPLS traffic engineering.

- - - - - - -

RFC 5880

Title

   Bidirectional Forwarding Detection (BFD)

Abstract

   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.  It operates
   independently of media, data protocols, and routing protocols.

- - - - - - -

RFC 5881

Title

   Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6
   (Single Hop)

Abstract

   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol over IPv4 and IPv6 for single IP hops.

- - - - - - -

RFC 5882

Title

   Generic Application of Bidirectional Forwarding Detection (BFD)

Abstract

   This document describes the generic application of the Bidirectional
   Forwarding Detection (BFD) protocol.


- - - - - - -

RFC 5883

Title

   Bidirectional Forwarding Detection (BFD) for Multihop Paths

Abstract

   This document describes the use of the Bidirectional Forwarding
   Detection (BFD) protocol over multihop paths, including
   unidirectional links.

- - - - - - -

RFC 5884

Title

   Bidirectional Forwarding Detection (BFD) for MPLS Label Switched
   Paths (LSPs)

Abstract

   One desirable application of Bidirectional Forwarding Detection (BFD)
   is to detect a Multiprotocol Label Switching (MPLS) Label Switched
   Path (LSP) data plane failure.  LSP Ping is an existing mechanism for
   detecting MPLS data plane failures and for verifying the MPLS LSP
   data plane against the control plane.  BFD can be used for the
   former, but not for the latter.  However, the control plane
   processing required for BFD Control packets is relatively smaller
   than the processing required for LSP Ping messages.  A combination of
   LSP Ping and BFD can be used to provide faster data plane failure
   detection and/or make it possible to provide such detection on a
   greater number of LSPs.  This document describes the applicability of
   BFD in relation to LSP Ping for this application.  It also describes
   procedures for using BFD in this environment.

- - - - - - -

RFC 5885

Title

   Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual
   Circuit Connectivity Verification (VCCV)

Abstract

   This document describes Connectivity Verification (CV) Types using
   Bidirectional Forwarding Detection (BFD) with Virtual Circuit
   Connectivity Verification (VCCV).  VCCV provides a control channel
   that is associated with a pseudowire (PW), as well as the
   corresponding operations and management functions such as
   connectivity verification to be used over that control channel.

- - - - - - -

RFC 5886

Title

   A Set of Monitoring Tools for Path Computation Element (PCE)-Based
   Architecture

Abstract

   A Path Computation Element (PCE)-based architecture has been
   specified for the computation of Traffic Engineering (TE) Label
   Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks in the context of single or
   multiple domains (where a domain refers to a collection of network
   elements within a common sphere of address management or path
   computational responsibility such as Interior Gateway Protocol (IGP)
   areas and Autonomous Systems).  Path Computation Clients (PCCs) send
   computation requests to PCEs, and these may forward the requests to
   and cooperate with other PCEs forming a "path computation chain".

   In PCE-based environments, it is thus critical to monitor the state
   of the path computation chain for troubleshooting and performance
   monitoring purposes: liveness of each element (PCE) involved in the
   PCE chain and detection of potential resource contention states and
   statistics in terms of path computation times are examples of such
   metrics of interest.  This document specifies procedures and
   extensions to the Path Computation Element Protocol (PCEP) in order
   to gather such information.

- - - - - - -

RFC 5920

Title

   Security Framework for MPLS and GMPLS Networks

Abstract

   This document provides a security framework for Multiprotocol Label
   Switching (MPLS) and Generalized Multiprotocol Label Switching
   (GMPLS) Networks.  This document addresses the security aspects that
   are relevant in the context of MPLS and GMPLS.  It describes the
   security threats, the related defensive techniques, and the
   mechanisms for detection and reporting.  This document emphasizes
   RSVP-TE and LDP security considerations, as well as inter-AS and
   inter-provider security considerations for building and maintaining
   MPLS and GMPLS networks across different domains or different
   Service Providers.

- - - - - - -

RFC 5921

Title

   A Framework for MPLS in Transport Networks

Abstract

   This document specifies an architectural framework for the
   application of Multiprotocol Label Switching (MPLS) to the
   construction of packet-switched transport networks.  It describes a
   common set of protocol functions -- the MPLS Transport Profile (MPLS-
   TP) -- that supports the operational models and capabilities typical
   of such networks, including signaled or explicitly provisioned
   bidirectional connection-oriented paths, protection and restoration
   mechanisms, comprehensive Operations, Administration, and Maintenance
   (OAM) functions, and network operation in the absence of a dynamic
   control plane or IP forwarding support.  Some of these functions are
   defined in existing MPLS specifications, while others require
   extensions to existing specifications to meet the requirements of the
   MPLS-TP.

   This document defines the subset of the MPLS-TP applicable in general
   and to point-to-point transport paths.  The remaining subset,
   applicable specifically to point-to-multipoint transport paths, is
   outside the scope of this document.

- - - - - - -

RFC 5950

Title

   Network Management Framework for MPLS-based Transport Networks

Abstract

   This document provides the network management framework for the
   Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

   This framework relies on the management terminology from the ITU-T to
   describe the management architecture that could be used for an MPLS-
   TP management network.

   The management of the MPLS-TP network could be based on multi-tiered
   distributed management systems.  This document provides a description
   of the network and element management architectures that could be
   applied and also describes heuristics associated with fault,
   configuration, and performance aspects of the management system.

- - - - - - -

RFC 5951

Title

   Network Management Requirements for MPLS-based Transport Networks

Abstract

   This document specifies the requirements for the management of
   equipment used in networks supporting an MPLS Transport Profile
   (MPLS-TP).  The requirements are defined for specification of
   network management aspects of protocol mechanisms and procedures
   that constitute the building blocks out of which the MPLS
   Transport Profile is constructed.  That is, these requirements
   indicate what management capabilities need to be available in
   MPLS for use in managing the MPLS-TP.  This document is intended
   to identify essential network management capabilities, not to
   specify what functions any particular MPLS implementation
   supports.

- - - - - - -

RFC 5960

Title

   MPLS Transport Profile Data Plane Architecture

Abstract

   The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
   set of MPLS protocol functions applicable to the construction and
   operation of packet-switched transport networks.  This document
   specifies the subset of these functions that comprises the MPLS-TP
   data plane: the architectural layer concerned with the encapsulation
   and forwarding of packets within an MPLS-TP network.

- - - - - - -

RFC 5994

Title

   Application of Ethernet Pseudowires to MPLS Transport Networks

Abstract

   Ethernet pseudowires are widely deployed to support packet transport
   of Ethernet services.  These services in-turn provide transport for a
   variety of client networks, e.g., IP and MPLS.  This document uses
   procedures defined in the existing IETF specifications of Ethernet
   pseudowires carried over MPLS networks.

   Many of the requirements for the services provided by the mechanisms
   explained in this document are also recognized by the MPLS transport
   profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T.
   The solution described here does not address all of the MPLS-TP
   requirements, but it provides a viable form of packet transport
   service using tools that are already available.

   This document also serves as an indication that existing MPLS
   techniques form an appropriate basis for the design of a fully-
   featured packet transport solution addressing all of the requirements
   of MPLS-TP.

- - - - - - -

RFC 6001

Title

   Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and
   Multi-Region Networks (MLN/MRN)

Abstract

   There are specific requirements for the support of networks
   comprising Label Switching Routers (LSRs) participating in different
   data plane switching layers controlled by a single Generalized Multi-
   Protocol Label Switching (GMPLS) control plane instance, referred to
   as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).

   This document defines extensions to GMPLS routing and signaling
   protocols so as to support the operation of GMPLS Multi-Layer /
   Multi-Region Networks.  It covers the elements of a single GMPLS
   control plane instance controlling multiple Label Switched Path (LSP)
   regions or layers within a single Traffic Engineering (TE) domain.

- - - - - - -

RFC 6002

Title

   Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC)
   and Channel Set Label Extensions

Abstract

   This document describes two technology-independent extensions to
   Generalized Multi-Protocol Label Switching (GMPLS).  The first
   extension defines the new switching type Data Channel Switching
   Capable.  Data Channel Switching Capable interfaces are able to
   support switching of the whole digital channel presented on single
   channel interfaces.  The second extension defines a new type of
   generalized label and updates related objects.  The new label is
   called the Generalized Channel_Set Label and allows more than one
   data plane label to be controlled as part of a Label Switched Path
   (LSP).

- - - - - - -

RFC 6003

Title

   Ethernet Traffic Parameters

Abstract

   This document describes the support of Metro Ethernet Forum (MEF)
   Ethernet traffic parameters as described in MEF10.1 when using
   Generalized Multi-Protocol Label Switching (GMPLS) Resource
   ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

- - - - - - -

RFC 6004

Title

   Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011
   Ethernet Service Switching

Abstract

   This document describes a method for controlling two specific types
   of Ethernet switching via Generalized Multi-Protocol Label Switching
   (GMPLS).  This document supports the types of switching corresponding
   to the Ethernet services that have been defined in the context of the
   Metro Ethernet Forum (MEF) and International Telecommunication Union
   (ITU) G.8011.  Specifically, switching in support of Ethernet private
   line and Ethernet virtual private line services are covered.  Support
   for MEF- and ITU-defined parameters is also covered.

- - - - - - -

RFC 6005

Title

   Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011
   User Network Interface (UNI)

Abstract

   This document describes a method for controlling two specific types
   of Ethernet switching via a GMPLS-based User Network Interface (UNI).
   This document supports the types of switching required by the
   Ethernet services that have been defined in the context of the Metro
   Ethernet Forum (MEF) and International Telecommunication Union (ITU)
   G.8011.  This document is the UNI companion to "Generalized MPLS
   (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service
   Switching".  This document does not define or limit the underlying
   intra-domain or Internal NNI (I-NNI) technology used to support the
   UNI.

- - - - - - -

RFC 6006

Title

   Extensions to the Path Computation Element Communication Protocol
   (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched
   Paths

Abstract

   Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
   MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
   be established using signaling techniques, but their paths may first
   need to be determined.  The Path Computation Element (PCE) has been
   identified as an appropriate technology for the determination of the
   paths of point-to-multipoint (P2MP) TE LSPs.

   This document describes extensions to the PCE communication Protocol
   (PCEP) to handle requests and responses for the computation of paths
   for P2MP TE LSPs.

- - - - - - -

RFC 6107

Title

   Procedures for Dynamically Signaled Hierarchical Label Switched Paths

Abstract

   Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
   (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
   to carry traffic in those networks or in other (client) networks.

   Protocol mechanisms already exist to facilitate the establishment of
   such LSPs and to bundle traffic engineering (TE) links to reduce the
   load on routing protocols.  This document defines extensions to those
   mechanisms to support identifying the use to which such LSPs are to
   be put and to enable the TE link endpoints to be assigned addresses
   or unnumbered identifiers during the signaling process.

   The mechanisms defined in this document deprecate the technique for
   the signaling of LSPs that are to be used as numbered TE links
   described in RFC 4206.

- - - - - - -

RFC 6073

Title

   Segmented Pseudowire

Abstract

   This document describes how to connect pseudowires (PWs) between
   different Packet Switched Network (PSN) domains or between two or
   more distinct PW control plane domains, where a control plane domain
   uses a common control plane protocol or instance of that protocol for
   a given PW.  The different PW control plane domains may belong to
   independent autonomous systems, or the PSN technology is
   heterogeneous, or a PW might need to be aggregated at a specific PSN
   point.  The PW packet data units are simply switched from one PW to
   another without changing the PW payload.

- - - - - - -

RFC 6119

Title

   IPv6 Traffic Engineering in IS-IS

Abstract

   This document specifies a method for exchanging IPv6 traffic
   engineering information using the IS-IS routing protocol.  This
   information enables routers in an IS-IS network to calculate traffic-
   engineered routes using IPv6 addresses.

- - - - - - -