Liaison statement
Recent GMPLS and ASON-Related RFCs publ;ished
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2007-02-21 |
From Group | ccamp |
From Contact | Adrian Farrel |
To Group | ITU-T-SG-15 |
To Contacts | Greg Jones <greg.jones@itu.int> |
Cc | Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com> Kam Lam <hklam@alcatel-lucent.com> Scott Bradner <sob@harvard.edu> Ross Callon <rcallon@juniper.net> Deborah Brungard <dbrungard@att.com> CCAMP <ccamp@ops.ietf.org> |
Response Contact | Adrian Farrel <adrian@olddog.co.uk> |
Technical Contact | Adrian Farrel <adrian@olddog.co.uk> |
Purpose | For information |
Attachments | (None) |
Body |
The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4558 http://www.ietf.org/rfc/rfc4558.txt Title Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Abstract Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol- Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. RFC 4652 http://www.ietf.org/rfc/rfc4652.txt Title Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements Abstract The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs). This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. RFC 4726 http://www.ietf.org/rfc/rfc4726.txt Title A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering Abstract This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). RFC 4736 http://www.ietf.org/rfc/rfc4736.txt Title Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) Abstract This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. RFC 4783 http://www.ietf.org/rfc/rfc4783.txt Title GMPLS - Communication of Alarm Information Abstract This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473, "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Deborah Brungard CCAMP Working Group chairs |