2.5.1 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-14


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 cooperate
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
Dec 03  Submit protection & restoration documents to IESG
Dec 03  Submit ASON signaling requirements doc to IESG
Jan 04  Submit ASON routing 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
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-04.txt
  • draft-ietf-ccamp-gmpls-g709-08.txt
  • draft-ietf-ccamp-gmpls-tc-mib-06.txt
  • draft-ietf-ccamp-gmpls-te-mib-06.txt
  • draft-ietf-ccamp-gmpls-lsr-mib-06.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-02.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-02.txt
  • draft-ietf-ccamp-crankback-03.txt
  • draft-ietf-ccamp-gmpls-egress-control-03.txt
  • draft-ietf-ccamp-gmpls-alarm-spec-01.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-00.txt
  • draft-ietf-ccamp-loose-path-reopt-00.txt
  • draft-ietf-ccamp-transport-lmp-00.txt
  • draft-ietf-ccamp-rsvp-restart-ext-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

    Current Meeting Report

    61st IETF CCAMP Minutes
    Minutes taken by
    Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou

    1. Admin and agenda bash - Chairs (5 min)
    Agenda bashing - no changes

    2. Status of WG drafts - Adrian (10 min)

    Drafts now unblocked, however the removal of the MPLS bundling draft has caused another snag.
    We have got two new RFCs, Architecture (3945) and SONET/SDH Extensions (3946).
    Six drafts are in the RFC Ed. queue.
    Five are in IETF Last Call.
    Two are in IESG review.
    15 active drafts - if you want a draft adopted as WG draft, let's finish these first!
    Tunnel trace in particular seems to have very little interest - will be discussed wrt to rechartering.

    Overall status: almost all milestones completed, should recharter or close in March '04!

    Lou - slide does not list all 15 drafts - others are still active? In particular Alarm_Spec
    Adrian - no intention to exclude, asked if implementation on alarm spec draft.
    Lou - at least one, possibly two,
    Kireeti - only need one, so Ok to go forward

    Adrian - Note: Node_Id based Hello has not been updated before deadline
    Adrian - Milestones and re-chartering will be covered at the end of the meeting.
    Dimitri Papadimitriou - Correction. Node_Id based hello was submitted in time. Updates for WG last call comments.

    3. Link Bundling - Zafar Ali
    -- Issues with current RFCs and drafts
    -- Draft removed from the RFC editor's queue
    -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and IF_ID_ERROR_SPEC, also recording of route
    -- Plan to address first two issues in an updated draft but component link recording will remain outside the scope of the bundling draft. Will allow but recommend against use of types 4/5.
    -- Work on recording/explicit control will be done in a separate ID. Home in MPLS or CCAMP?

    -> see slides

    -- Plans
    Pulled from queue (reviewed slides)

    Adrian: procedure -> MPLS WG own document. Do review on what happens in this WG
    Note: speed is really important as we have multiple blocking documents in the CCAMP WG queue.

    Kireeti: This is not free for all on the bundling draft - change to be proposed and to be sent on the list (delta only)

    George: as MPLS chair, MPLS group plans to do updates quickly - considered as last call comments

    4. ASON Signaling Solutions - Dimitri P (5min)


    -- ASON signaling - no updates but lots of thinking esp. call setup message naming (Notify vs. specialized message), desire not to "piggyback" call information in the connection message. Expect finalized draft around Christmas time.
    -- ASON routing solutions design team
    - Evaluation of common "pattern" has taken time, evaluation document should be issued by end- November.
    - Model shown - use of terminology - what is TE Router ID, what is OSPF Router ID?
    - Further considerations - control plane does not transport the actual transport plane ids, but its view of the transport plane, using an associated IP addressing space.
    - No internal structure is associated with an abstract node.
    - Hierarchy focus is on exchange of information between peers.
    - Representation of bandwidth needs further thought.
    Adrian: it seems the DT has been making good progress, CCAMP WG has unfortunately not been aware of the progress, progress must be shown to the group by either sending status or updating the draft.
    Dimitri: will mail to the list.
    Zafar Ali: how does this work relate to the OSPF and ISIS groups?
    Dimitri: we are evaluating what may be missing, after this evaluation we can address protocol-specific issues.
    Zafar: Are you looking at existing mechanisms?
    Dimitri: global applicability is next step, currently looking at what info is exchanged

    5. ITU Liaison - Lyndon Ong

    -- ITU continues to be interested in converging the work on signaling and routing
    -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the last Q14 meeting
    -- ITU is currently working on ASON management specifications and thanks CCAMP for its liaison of the GMPLS MIB work for its review
    Zafar: can we also have a report of OIF status?
    Chairs and Lyndon: there is nothing formal to report at this time that's why it was not scheduled on the agenda. However, liaisons will be sent to the mailing list for everyone's review, and if something formal is made available, it will be scheduled.
    Lyndon: - there is ongoing discussion and communication just sent back to IETF
    Adrian: but not there yet (not available)
    Lyndon: is there a need for a permanent liaison from the OIF at the CCAMP meeting?
    Adrian: if there is something to be discussed it will be considered on a per-request/per-case basis

    6. Graceful Shutdown - Zafar Ali (10 min)

    -- Intention is to support a planned shutdown, e.g., for maintenance purposes
    -- IGP based solution does not cover Inter-AS/Area scenarios
    -- RSVP-based solution does not convey information to all nodes in the network.
    -- Both mechanisms must complement each other
    -- Use existing sub-code of the Path Error message, then perform make-before-break for the LSP. Proposed changes are minor and based on existing framework.
    -- Would like to propose this ID as a WG document
    Rahul: is this intra or inter? inter-domain can use hierarchy of LSPs (nesting/stitching) to achieve this isolation.
    Zafar: recognize both mechanisms
    Rahul: we should clarify these aspects, as well as inter-domain TE aspects.
    Zafar: can add these aspects in the document
    Richard Rabbat: why is this GMPLS rather than MPLS?
    Zafar: could be shutting down any type of link.
    Adrian: in terms of problem space it is needed in both cases
    Igor Bryskin: this is a data plane problem followed by rerouting - why don't we use existing mechanisms such as propagating alarms?
    Zafar: distinguish this from alarms as this is not something that requires an immediate reroute. This is not intended to tackle data plane alarms
    Kireeti: maintenance of the link/node - out-of-service issue is to get traffic out of the link
    Igor: alarms do not only mean "failure". Could it use alarm severity?
    Kireeti: not an alarm situation.
    Adrian: this is maintenance alarm => requires to scope the work
    Igor: Tools already exist to trigger the same thing, the existing tools are more powerful than this proposed one
    Zafar: point to the capability of the mechanism having the indication to perform make-before-break - also suggest put on the list what you think are alternative mechanisms
    Lou Berger: if we do this, we should use existing mechanisms such as admin status or alarm (Arthi's suggested one, Igor's alarm admin status)
    Zafar: this mechanism is already in the spec - JP's re-optimization draft
    Lou: other mechanisms are in RFCs. We should decide on mechanisms before we accept as a WG draft.
    Kireeti: step back from the solution, so the point is to write down what is to be achieved (take things out gracefully) -> need first to look at requirements for what want to do.
    Zafar: agreement

    7. Interdomain Framework - Adrian (5min)
    -- Minor changes since last time, but published as WG draft
    -- Applies to both MPLS and GMPLS, but currently limited to simpler functions for initial work
    -- Realize need more discussion on definition of "domain" e.g. Nested domains, ensure GMPLS included. Will take to list for discussion.
    -- This covers "simple" functions, what about "advanced" functions such as diverse paths, mapping domain-specific constraints such as DiffServ, pt-to-mpt, etc.?
    -- Adrian's suggestion is to keep this separate for convenience.
    Rahul: MPLS OAM - building blocks are in place, so it can go in this document; P2MP is considerably less well understood.
    Kireeti: what about GMPLS OAM?
    Dimitri: need to understand what we mean by GMPLS OAM. Suggest phased approach.

    8. Interdomain TE Requirements - Tomohiro Otani (5min)

    -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
    -- Changes: added section identifying the following general requirements
    - EGP extensions for GMPLS
    - GMPLS Inter-AS signaling, path calculation and recovery
    - GMPLS interdomain TE management
    -- Remaining issues:
    - Investigate added load created by EGP extensions
    - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
    - Propose WG document
    Zafar: recommended would be a good basis for inter-domain TE framework
    Arthi: support effort, but has too many solutions-related aspects in it. Also suggest separating requirements into signaling, routing and path computation. Need to clarify what is meant by domain - refer to framework document.
    Dimitri: what about reachability information exchange? Not addressed, but will be an important aspect.
    Adrian: this is solution, not requirements. Suggest to separate requirements and solutions. General approval of the work, but need to remove solutions. Should consider reachability as well as TE aspects. Restructure as Arthi suggests.
    Otani: agree, will separate
    Kireeti summarizing: separate requirements from solution and structure: signaling from routing (in part. reachability)

    9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
    -- Scope issues
    - No intent to come up with new interdomain routing paradigm
    - Scoped applicability to a limited number of TE LSPs
    - Scoped to a "simple" topology of ASes or areas
    -- Previous BOF - clear requirements from many SPs and common theme of problem - MPLS TE LSP path computation
    -- Architecture - comments noted global picture needed, but no standardization of architecture. New revision to be submitted soon in the meantime please comments!
    -- Note agreed no intention to extend LDP, but possibly other protocols
    -- Agreed on proposed charter and milestones, proposal to be sent out early next week.
    -- Many in favor of new WG, none against - need IESG review and work on charter
    Bijan Jabbari: what scale of LSPs?
    JP: no specific number, not full mesh - does this mean no scalability concerns?
    Adrian: need to make the problem manageable, at least initially.
    Bijan: will WG be open to new architectures?
    Kireeti: take this to the list.
    Peter Toms: support this, lots of requests for this.

    10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
    -- Changes - include separate section on stitching and required extensions, clarifications for non-packet LSPs.
    -- Request to make it a WG document - none against, but limited number agreeing (note: not many read the draft)- list.
    Adrian: stitching has wider applicability - should we pull it out into a separate draft?

    11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)

    -- Adrian not that familiar with this draft. Flags one slide on message exchange where the head end is in the center rather than at the end. Notes several claim, explicitly claim of no new protocol seems questionable as new objects are defined. Need further feedback.
    -- Can't take questions as no authors present to discuss - take to list

    12. Related to 11. Protection for Inter-AS tunnels - Decnodder - Cristel
    -- Differs from 11
    -- Addresses requirements from TEWG draft
    -- Uses RSVP-TE and FRR
    -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
    -- Looking for feedback, how to generalize to GMPLS
    Adrian: need to apply to GMPLS if you want the draft to be in this group
    Zafar: SRLG issue - need to solve the scooping issue, applies in a number of places.
    Adrian: WG should look at a framework for diverse paths, including PCE
    Zafar: needs more discussion to understand, and already work in MPLS WG on ABR protection.
    Adrian: authors can continue draft, would also like for CCAMP to evaluate if PCE is appropriate, or something else
    JP: should include the PCE mailing list on this.
    Adrian: need discussion on the ccamp list.

    13. Requirements for multi-region - Kohei Shiomoto

    -- Region defined based on switching capability - note region is control plane, layer is data plane
    -- Addresses pre-provisioned FA, triggered FA and no FA cases. Plain and hybrid type nodes.
    -- Architecture has generated requirements and solutions drafts
    -- Virtual network topology, application example
    -- Propose as WG document.
    Adrian: handling regions are in scope of CCAMP.
    Adrian: asks Dimitri to immediately present the extensions then we will take questions

    Dimitri Papadimitriou

    -- TE metric inheritance - how to inherit or map metrics
    -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
    -- Reconvergence of VNT
    -- Handling multiple switching and adaptation capabilities
    Zafar: is this a good idea from TE point of view - dynamic FA creation - need applicability statement - potential bandwidth segmentation issues - may lose aggregation that you would normally get at the boundary - could add oscillation. If still considered a good idea, should it be triggered by signaling or some other mechanism? Document needs to list concerns.
    Arthi: some parts of requirements still not clear - what is needed outside of the LSP hierarchy draft? Need to clarify what is missing from the existing, and reference where it's covered by existing documents. Don't want to reinvent terminology. Regarding virtual FA setup can be pre-provisioned or on demand - hierarchy draft already says this, should not be in the requirements document but only in the solutions document. Regarding protection - more work needs to be done in the requirements.
    Igor: region, layer, hierarchy level are treated interchangeably in the draft, confusing. Regarding stitching, this is a very general capability and should be in LSP hierarchy instead.
    Kireeti: thinks this should have a separate document.
    Adrian: more clarification would be good on layer/region
    Jonathan Sadler: good stuff in general, agree with the goal. Concern is that IETF framework is not well aligned to ITU concept of layered network (G.805). It would be good to take into account the ITU framework. Work on extensions is premature at this time.
    Deborah Brungard: authors intended to handle multiple layers as in ITU (e.g. G.805) - limited to single domain for now, should be addressed to GMPLS RFCs. Not intended to discuss data plane concepts. Request for more specific comments.

    14. MPLS-to-GMPLS Migration - Kohei Shiomoto

    -- Evolution from legacy MPLS to GMPLS -
    -- Differences: architecture (C/D separation, bidirectionality, P&R); routing (opaque LSA); signaling (new objects, messages)
    -- Propose WG document
    Kireeti: question on whether this is in scope - address on charter
    Zafar: multi-layer comments also apply here.
    Richard Rabbat: supports the work, suggests looking at more generic numbers of regions (not just 2 or 3).
    Ping Pan: how does this differ from the overlay model?
    Kireeti: different, take this to the list.

    15. L1 VPN - Tomonori Takeda (10 Min)

    -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
    -- Two drafts applicable, ouldbrahim and overlay - guidelines for enhancement, deployment scenaros - added terminology refinement, security considerations, service models
    -- Further comments solicited, planning further liaison to SG13.
    -- Applicability draft examines existing GMPLS protocols for L1 VPN services. Has added Deborah as co-author.
    -- Concept - set up FA LSP between PEs, use stitching to connect this to CEs.
    -- Propose to adopt as CCAMP charter item.
    Kireeti: supports applicability draft. Liaison with ITU is very
    important - we need to be responsive. We will discuss this item as part of the extension of the CCAMP charter

    16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)

    -- ATM, FR, ETH, etc. Defines label request processing, label semantics, added security section.
    -- Security - threats analysis, attacks on the data plane, L2 LSP signaling, attacks on control plane
    -- Ask for WG draft, no plan to respin
    Dave Allan: Question on Ethernet VLAN tag swapping - not defined in IEEE.
    Dimitri: intended to cover GMPLS scope, not data plane. Should not assume tag is per port unique.
    Don Fedyk: is this P2P?
    Dimitri: Yes (as starting point).
    Kireeti: ok, we have a fair consensus, so I would say it's a rough consensus point. We will take this to the list, Dave and Dimitri to work out VLAN issue.
    Adrian: Note that an MPLS group draft on L2 has come up

    17. Mesh Carrier Survey - Richard Rabbat (5 min)

    -- Initially 7 carriers polled, open to others
    -- Also surveys GMPLS control plane deployment
    -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
    -- Concerns with stability, signaling storms
    -- Asking for feedback, new carrier input
    Richard: review slides, recommend for CCAMP WG to begin work on shared mesh restoration performance

    18. Milestone and Charter discussion - Kireeti

    -- Current activities winding down, esp. P&R, ASON
    -- Others underway, esp. multi-domain
    -- New: migration, VPNs, control plane resilience, addressing, implementation experience, GTTP (?)
    -- Migration
    - GMPLS supersets MPLS, but some objects are different - label request, label, upstream label
    - Need BCP on smooth migration, what issues may occur
    -- L1 VPN
    - Should IETF do this? Should it be in CCAMP? Tied to UNI and Interdomain signaling
    -- Control plane resilience - includes graceful restart but also more
    -- Addressing - transport networks use different kinds of addresses
    - need decoder ring for mapping transport network address types to IP addresses
    - Kireeti considers this useful
    -- Interop results
    - note that addressing pops up there as well. BCPs would be helpful
    -- Send out request for new work items, replies due Friday 11/19.
    -- Send out checks for consensus on each item, replies due Friday 12/3
    -- Send resulting list to A-Ds, trimmed if necessary, add appropriate milestones
    -- Consensus is a requirement but not a guarantee.
    Lou: how about dropping something from the existing charter
    Kireeti: maybe GTTP
    Lou: should note on the list also things that may be dropped if no support
    Alex Zinin: about L1 VPNs - is this research work, or practical? Need at least one implementation - is anyone implementing this within a year or two?
    Dimitri: Solutions exist provided by vendors today, but no common
    framework. Timeframe for implementation is 18-24 months.
    Alex: remind the group of the need for running code.
    Adrian: what about informational draft on how to use existing functions to do the service? Is there any interest from the research groups or the real carrier deployment groups?
    Tomonori Takeda: NTT has interest, but not sure of protocols. Timeframe cannot say. Testing is done.
    Yakov Rekhter: vendors cannot disclose future product plans...
    Deborah Brungard: carriers also cannot disclose plans, will see interest by number of co-authors.
    Kireeti: have had carriers ask for this technology. We don't have all the pieces, but have implemented many of them, and as a vendor would like to see a solution on how to do. Answer to Alex is yes.
    Richard Rabbat: could add this to his survey.
    Kireeti: supports this.



    Agenda and chairs
    Bundling issues
    ASON signaling solutions
    ASON routing solutions design team status
    ITU-T liaison
    Graceful shutdown
    Inter-domain framework
    GMPLS Inter-AS requirements
    Status of the PCE BOF
    Inter-domain signaling
    Multi-region requirements
    Multi-region solutions
    Inter-region path setup
    Inter-AS protection path establishment
    MPLS/GMPLS migration
    Layer one VPNs
    Layer two switching capabilities
    Mesh protection carrier survey
    CCAMP re-chartering