The CCAMP working group of the IETF would like to inform you of
the publication of several new RFCs (Request for Comment) that may
be relevant to your work.
RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
This document describes protocol-specific procedures and extensions
for Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to
support end-to-end Label Switched Path (LSP) recovery that denotes
protection and restoration. A generic functional description of
GMPLS recovery can be found in a companion document, RFC 4426.
GMPLS Segment Recovery
This document describes protocol specific procedures for GMPLS
(Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
ReserVation Protocol - Traffic Engineering) signaling extensions to
support label switched path (LSP) segment protection and
These extensions are intended to complement and be consistent with
the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
Implications and interactions with fast reroute are also addressed.
This document also updates the handling of NOTIFY_REQUEST objects.
Exclude Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)
This document specifies ways to communicate route exclusions during
path setup using Resource ReserVation Protocol-Traffic Engineering
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Resource
Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
abstract nodes and resources to be explicitly included in a path
setup, but not to be explicitly excluded.
In some networks where precise explicit paths are not computed at
head end, it may be useful to specify and signal abstract nodes and
resources that are to be explicitly excluded from routes. These
exclusions may apply to the whole path, or to parts of a path
two abstract nodes specified in an explicit path. How Shared Risk
Link Groups (SRLGs) can be excluded is also specified in this
Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)
This document describes extensions to Resource Reservation Protocol
Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. The solution relies on RSVP-TE without requiring a
multicast routing protocol in the Service Provider core. Protocol
elements and procedures for this solution are described.
There can be various applications for P2MP TE LSPs such as IP
multicast. Specification of how such applications will use a P2MP
LSP is outside the scope of this document.
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
In a distributed, constraint-based routing environment, the
information used to compute a path may be out of date. This means
that Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
requests may be blocked by links or nodes without sufficient
resources. Crankback is a scheme whereby setup failure information
is returned from the point of failure to allow new setup attempts
be made avoiding the blocked resources. Crankback can also be
applied to LSP recovery to indicate the location of the failed link
This document specifies crankback signaling extensions for use in
MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description", RFC 3473. These extensions mean that the
LSP setup request can be retried on an alternate path that detours
around blocked links or nodes. This offers significant
in the successful setup and recovery ratios for LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.
Routing Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
The setup of a full mesh of Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
Label Switch Routers (LSR) is a common deployment scenario of MPLS
Traffic Engineering either for bandwidth optimization, bandwidth
guarantees or fast rerouting with MPLS Fast Reroute. Such
may require the configuration of a potentially large number of TE
LSPs (on the order of the square of the number of LSRs). This
specifies Interior Gateway Protocol (IGP) routing extensions for
Intermediate System-to-Intermediate System (IS-IS) and Open
Path First (OSPF) so as to provide an automatic discovery of the
of LSRs members of a mesh in order to automate the creation of such
mesh of TE LSPs.
All IETF RFCs can be downloaded for free from
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
As always, 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.
Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group