2.5.2 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional CCAMP Web Page

Last Modified: 2005-01-07


Kireeti Kompella <kireeti@juniper.net>
Adrian Farrel <adrian@olddog.co.uk>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Technical Advisor(s):

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: http://ops.ietf.org/lists/ccamp

Description of Working Group:

Organizational Overview

The CCAMP working group coordinates the work within the IETF defining
a common control plane and a separate common measurement plane for
physical path and core tunneling technologies of Internet and telecom
service providers (ISPs and SPs), e.g. O-O and O-E-O optical
switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation
with the MPLS WG. In this context, measurement refers to the
acquisition and distribution of attributes relevant to the setting up
of tunnels and paths.

CCAMP WG work scope includes:

- Definition of protocol-independent metrics and parameters
  (measurement attributes) for describing links and paths that are
  required for routing and signaling. These will be developed in
  conjunction with requests and requirements from other WGs (e.g.
  TEWG) to insure overall usefulness.

- Definition of protocol(s) and extensions to them required for
  link and path attribute measurement. Link Management Protocol (LMP)
  is included here.

- Functional specification of extensions for routing (OSPF, ISIS) and
  signalling (RSVP-TE) required for path establishment. Protocol
  formats and procedures that embody these extensions will be done
  jointly with the WGs supervising those protocols.

- Definition of the mechanisms required to determine the route and
  properties of an established path (tunnel tracing).

- Definition of MIB modules relevant to the protocols and extensions
  specified within the WG.

CCAMP WG currently works on the following tasks:

- Define how the properties of network resources gathered by a
  measurement protocol can be distributed in existing routing
  protocols, such as OSPF and IS-IS. CCAMP defines the generic
  description of the properties and how they are distributed in OSPF.
  The specifics of distribution within IS-IS are being addressed in
  the ISIS WG.

- Define signaling and routing mechanisms to make possible the creation
  of paths that span multiple IGP areas, multiple ASes, and multiple
  providers, including techniques for crankback.

- Define abstract link and path properties needed for link and path
  protection. Specify signalling mechanisms for path protection,
  diverse routing and fast path restoration. Ensure that multi-layer
  path protection and restoration functions are achievable using the
  defined signalling, routing, and measurement protocols, either
  separately or in combination.

- Identify which requirements for signaling and routing for ASON are
  not currently met by protocols defined in CCAMP; based on these,
  define mechanisms to address these requirements.

- Define a protocol that can determine the actual route and other
  properties of paths set up by CCAMP signaling protocols, as well
  as other types of tunnels (tunnel tracing).

In doing this work, the WG will work closely with at least the
following other WGs: TEWG, MPLS, ISIS, OSPF. The WG will also
with ITU-T.

Goals and Milestones:

Done  Post strawman WG goals and charter
Done  Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts.
Done  Build appropriate design teams
Done  Submit WG document defining path setup portions of common control plane protocol
Done  Submit WG document defining common measurement plane protocol
Done  Submit LMP MIB to IESG
Dec 03  Submit GMPLS MIBs to IESG
Done  Submit protection & restoration documents to IESG
Done  Submit ASON signaling requirements doc to IESG
Done  Produce CCAMP WG document for generic tunnel tracing protocol
Done  Produce CCAMP WG document for multi-area/AS signaling and routing
Done  Submit ASON routing requirements doc to IESG
Mar 04  Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG


  • draft-ietf-ccamp-lmp-10.txt
  • draft-ietf-ccamp-gmpls-routing-09.txt
  • draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
  • draft-ietf-ccamp-lmp-mib-10.txt
  • draft-ietf-ccamp-lmp-wdm-03.txt
  • draft-ietf-ccamp-sdhsonet-control-05.txt
  • draft-ietf-ccamp-gmpls-g709-09.txt
  • draft-ietf-ccamp-gmpls-tc-mib-06.txt
  • draft-ietf-ccamp-gmpls-te-mib-08.txt
  • draft-ietf-ccamp-gmpls-lsr-mib-07.txt
  • draft-ietf-ccamp-gmpls-recovery-terminology-05.txt
  • draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
  • draft-ietf-ccamp-gmpls-overlay-05.txt
  • draft-ietf-ccamp-gmpls-recovery-analysis-04.txt
  • draft-ietf-ccamp-gmpls-ason-reqts-07.txt
  • draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
  • draft-ietf-ccamp-gmpls-recovery-functional-03.txt
  • draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
  • draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt
  • draft-ietf-ccamp-crankback-04.txt
  • draft-ietf-ccamp-gmpls-alarm-spec-02.txt
  • draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
  • draft-ietf-ccamp-tunproto-01.txt
  • draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
  • draft-ietf-ccamp-gmpls-segment-recovery-01.txt
  • draft-ietf-ccamp-inter-domain-framework-01.txt
  • draft-ietf-ccamp-loose-path-reopt-00.txt
  • draft-ietf-ccamp-transport-lmp-01.txt
  • draft-ietf-ccamp-rsvp-restart-ext-01.txt
  • draft-ietf-ccamp-inter-domain-rsvp-te-00.txt

    Request For Comments:

    RFC3471 PS Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
    RFC3472 PS Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
    RFC3473 PS Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
    RFC3609 I Tracing Requirements for Generic Tunnels
    RFC3945 Standard Generalized Multi-Protocol Label Switching Architecture
    RFC3946 Standard Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control
    RFC4003 Standard GMPLS Signaling Procedure For Egress Control

    Current Meeting Report

    Common Control and Measurement Plane WG (ccamp)

    Tuesday, March 8, 2005 at 0900-1130
    Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen

    Working group status - chairs
    - No changes to the agenda made.
    - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months.
    - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls.
    * Dimitri asked about IPR assertion on re-optimization draft
    - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do.
    - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject.
    - JP said we can take that as a way to go forward and continue technical work.

    ASON considerations

    ITU liaison - Lyndon Ong presented Wesam's slides
    - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings
    - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work.
    - There are two liaisons from ITU to CCAMP on the way.
    - Routing - ITU not planning any routing exts work, looking to IETF's work.
    - Continuing work on ASON management.
    - An FTP site is available for liaison statements.
    * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent?
    - Lyndon said a meeting is upcoming and will ask for it to be considered.
    * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet?
    - Adrian - RFC is desirable, not required?
    - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication.
    * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it.
    - Adrian - can that be liaised to us?
    - Steve Trowbridge - Yes, we can do that.

    ASON Routing Evaluation
    * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives.
    - Adrian will work with Steve to formalize the process.
    * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft
    - we will take to the list to see if any objection.
    * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call.
    - Adrian - we can liaise the draft and our intention to consider it
    as a WG draft

    Lexicography draft (Adrian)
    - Q14 indicates meeting went well, authors summarized comments and incorporated in this release.
    * Adrian asked if should be WG draft
    - Kireeti said we could do that, need to ask the list, also need to compare with G.8081
    * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions?
    - Adrian thinks there are good terms, though in multiple RFCs/drafts.
    - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions.
    - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it.

    Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
    LSP Stitching (Arthi)
    - Need feedback on several items.
    * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft.
    * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects?
    - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well.
    * Dimitri - if allow stitching of end-to-end LSP with LSP segment through different switching caps, then this changes the LSP switching type along the path and thus this becomes a FA
    - Arthi - but end-to-end does not change.
    * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration.
    - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired.
    - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list.
    * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here.
    * Lou - sw cap can change hop by hop just needs to match end to end of hop.
    - Arthi - agree, we were thinking the same.
    * Discussion sent to mailing list

    Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP)
    routing and path computation aspects.
    * Zafar asked clarification on ccamp-pce relationship
    - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path.
    - JP - ok
    * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list.

    Automesh (JP)
    - Agreement to rehash work a bit to put these together.
    - Now 2 drafts
    - Not a new ID, no changes.
    - Deployed networks using that.
    - No major changes planned
    * Igor - asked how to reflect constraints in a node for switching?
    - JP - we are discussing auto mesh, not node switching.
    - Igor - but how do we reflect node capabilities?
    - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap)
    - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement.
    - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh.
    - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list.

    Routing extensions for discovery of TE node capabilities (JL Le Roux)
    * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups.
    * Dimitri - should for terminology call TE router?
    - JL - yes.
    - Dimitri - should the TLV be exclusive to this function?
    - JL - yes.
    * Igor - how to distinguish node capabilities?
    - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list.
    * JL asked that this be adopted as a WG document.
    - Adrian - Take it to the list

    Extensions to GMPLS RSVP graceful restart (Lou Berger)
    * Adrian - do editorial respin, let us know, and we will take to last call
    * Any implementations?
    - Yes - two!

    Requirements (Kohei Shiomoto)
    Evaluation draft (JL Le Roux)
    Protocol extensions (Dimitri)
    * Arthi - what does virtual FA have to do with MRN, isn't it general?
    - Dimitri - should we have a specific doc on virtual FA for wider scope?
    - Arthi - did you want to scope only to MRN context?
    - Dimitri - no, just not sure if soln doc should be split.
    - Arthi - could be general - so prefer a separate doc on virtual FA.
    * Zafar - we need to give a priority capability for TE.
    - Dimitri - new TLV may be needed to describe relationships of multiple interfaces
    * Zafar - how relates to hierarchy draft?
    - Dimitri - maybe should be as applicability statement,
    - Kireeti - should do on mailing list
    * Kireeti - requests to continue work, when re-charter will consider for WG drafts.

    Routing considerations and CSPF for inter-as (Tomohiro Otani)
    * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider.
    - Otani - ok, we need more on summarizing capability.
    * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc.
    * Otani - how to handle inter-as cspf constraints?
    - Kireeti - as noted before (continue work).

    L2LSP (Dimitri)
    * Adrian asked clarification, is this "single hop"?
    - Dimitri - multiple hops each is a LSR, will clarify this in draft
    * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages
    - Dimitri - ok

    GMPLS addressing (Richard Rabbat)
    * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again.
    * Adrian asked for feedback on the topics, not the technical content initially.
    * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft)
    * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one.
    * Lou - should we wait for re-spin or now?
    - Kireeti - wait for re-spin.

    L1VPN (Tomonori Takeda)
    Framework draft
    Applicability draft
    * Alex - by next IETF will decide if it should be included in ccamp or as separate WG.

    Control plane saturation (JL Le Roux)
    * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ?
    * Kireeti - because of time, lets do on list.

    Graceful shutdown (Zafar Ali)
    * Kireeti - will consider for wg doc after re-charter
    * JP - is this part of current charter
    - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter.

    Deployment-augmented (Zafar Ali)
    * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ?
    - Zafar - no just TE link

    GMPLS interworking (Kenji)
    * Dimitri - why need to adv priority of LSP?
    - Adrian - need to ask on list.

    GMPLS interworking (Kohei Shiomoto)
    * Adrian - WG doc will be decided after re-charter
    - Welcome that will merge with other draft on augmented,
    - Suggest also look at Kenji's interworking draft to merge.

    Cho - ARP signal
    * Kireeti - request work with Dimitri on framework draft,
    - When decide direction and interactions with other SDO, may decide to form a design team to work on L2,
    - First we need a framework.


    Status of WG drafts and milestones
    Liaison Statements from ITU-T SG15
    Lexicography for using GMPLS in an ASON environment
    Inter-domain signaling
    LSP Stitching
    Inter-domain Path Computation
    Node capabilities
    Extensions for RSVP-TE Restart
    Multi-region requirements, extensions and protocol evalutaion
    Layer 2 Switching (L2SC)
    Inter-AS Requirements
    Inter-AS Requirements and CSPF Constraints
    GMPLS Interoperability and Addressing
    Layer One VPNs
    Control Plane Saturation
    Graceful Shutdown
    Augmented Model Deployment
    MPLS/GMPLS Interworking
    MPLS/GMPLS Migration
    GMPLS control of Ethernet Networks