Protocol Action: 'Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls' to Proposed Standard

[The IESG <iesg-secretary@ietf.org>]

The IESG has approved the following document:

- 'Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of 
   Calls '
   <draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt

Technical Summary
 
   In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service. Such associations are known as Calls.

   A Call does not provide the actual connectivity for transmitting user
   traffic, but only builds a relationship by which subsequent
   Connections may be made. In Generalized MPLS (GMPLS) such Connections
   are known as Label Switched Paths (LSPs).

   This document specifies how GMPLS RSVP-TE signaling may be used and
   extended to support Calls. These mechanisms provide full and logical
   Call/Connection separation.

   This creates a building block that is useful for other CCAMP
   efforts (GMPLS support for VCAT, GMPLS control of MS-SPRing,
   ASON, ... -- see PROTO writeup). 
 
Working Group Summary
 
   No dissent reported. Some have questioned whether this was needed, 
   but the need is becoming clearer as other CCAMP work progresses. 
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG. There is at least one 
   implementation. Also, the document has been updated based on 
   Security Directorate comments by Magnus Nyström, Gen-ART comments
   from Suresh Krishnan, and an IANA question from Yoshiko Chong. 

Note to RFC Editor
 
  please update Section 9.1, paragraph 3 as follows:

  OLD:
    Note, additionally, that the process of independent Call
    establishment, where the Call is set up separately from the LSPs, may
    be used to apply an extra level of authentication and policy for the
    end-to-end LSPs above that which is available with Call-less,
    hop-by-hop LSP setup.

  NEW:
    Note, additionally, that it would be desirable to use the process
    of independent Call establishment, where the Call is set up
    separately from the LSPs, to apply an extra level of authentication
    and policy for the end-to-end LSPs above that which is available
    with Call-less, hop-by-hop LSP setup.  However doing so will
    require additional work to set up security associations between the
    peer and the call manager that meet the requirements of [RFC4107].
    The mechanism described in this document is expected to meet this
    use case when combined with this additional work.  Application of
    this mechanism to the authentication and policy use case prior to
    standardization of a security solution is inappropriate and outside
    the current applicability of the mechanism.

  Also, please update some out of date references. Please
  reference RFC 4302 instead of RFC 2402, and reference RFC 4303
  instead of RFC 2406.


IESG Note

 (Insert IESG Note here)

IANA Note

 (Insert IANA Note here)