2.5.2 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

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
Nov 03  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  Produce CCAMP WG document for multi-area/AS signaling and routing
Jan 04  Produce CCAMP WG document for generic tunnel tracing protocol
Jan 04  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-gmpls-sonet-sdh-08.txt
  • - draft-ietf-ccamp-gmpls-architecture-07.txt
  • - 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-07.txt
  • - draft-ietf-ccamp-lmp-wdm-02.txt
  • - draft-ietf-ccamp-sdhsonet-control-02.txt
  • - draft-ietf-ccamp-gmpls-g709-04.txt
  • - draft-ietf-ccamp-gmpls-tc-mib-02.txt
  • - draft-ietf-ccamp-gmpls-lsr-mib-02.txt
  • - draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
  • - draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
  • - draft-ietf-ccamp-gmpls-overlay-02.txt
  • - draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
  • - draft-ietf-ccamp-gmpls-ason-reqts-04.txt
  • - draft-ietf-ccamp-rsvp-te-exclude-route-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

    Current Meeting Report

    CCAMP Working Group.
    58th IETF Minneapolis
    Monday 10th November 2003 0900-11.30
    Kireeti Kompella <kireeti@juniper.net> 
    Adrian Farrel <adrian@olddog.co.uk> 
    Agenda bashing (chairs)
    Minute takers and blue sheets (chairs)
    Minute takers: Dimitri Papadimitriou
                   Deborah Brungard
                   Eric Gray
    Thanks to Ron Bonica for co-chairing
    Thanks to Adrian Farrel for taking over as co-chair
    Old charter (chairs)
    Groundwork and critical work is completed, thus re-charter.
    New charter (chairs)
    - Multi-area/multi-as using tewg mpls requirements as input 
    - GMPLS ASON (input from ITU-T) look at the requirements and then 
    address them
    - Short charter for 6 months and move forward
    - Lots of interactions with the MPLS and IGP WG's
    - Short term focus of the WG on the charter milestones therefore new 
    material at bottom of the agenda (thus take it to the list if this is not 
    covered during this meeting)
    Drafts in 'final stages' (chairs)
    - Routing drafts: comments received from IESG (cleared yesterday)   
    - 2 drafts in IETF 4 weeks last call: LMP-SONET-SDH and LMP-WDM
    - 2 drafts pending: LMP-MIB and SDH/SONET-Control (with Bert and Alex for 
    Work in progress (chairs)
    - GMPLS UNI (overlay): needs one week WG last call
    - GMPLS for G.709: look for WG last call but positive comments needed to 
    move forward so will ask via mailing list if there is interest or not in 
    progressing and if any issues, 
    - Routing exclusion: new version is imminent (revision to be published just 
    after the meeting)
    Summary of interactions with other WGs (chairs)
    - TE WG:         Multi-area/AS requirements (mpls only)
    - MPLS WG:       P2MP Requirements
    - OSPF/IS-IS WG: GMPLS extensions completed now starting new item on ASON 
    Routing requirements (Design Team)
    - IPO WG:        Framework document 
    ITU-T Liaison (Wesam Alanqar)
    - Kireeti Kompella: noted that an ITU Recommendation can have CR-LDP as a 
    normative reference, that's ok, but for future need to discuss among 
    chairs/ADs (this will be done off-line)
    - Alex Zinin: CR-LDP code-points liaison, for the time this normative 
    reference is ok but for the future will need to clarify the liaison
    - Kam Lam: ITU-T SG15/Q14 Feb04 interim meeting, in San Jose or North 
    Carolina (not decided yet) - invites participants from CCAMP
    - Kam Lam: setup of a common FTP server / website
    GMPLS MIBs (Tom Nadeau)
    Tom Nadeau presented an update on the GMPLS MIB status.
    - Three drafts - fairly stable, one more round of IESG review for MPLS MIBs 
    (these MIBs depend on the status of the MPLS MIBs). 
    - Will publish updated MIB IDs after this meeting. 
    - Need to extend conformance, performance tables, consider how to expose 
    more information about hops (tunnel heads, tails and 
    intermediates), etc.
    - Need to determine whether or not discriminated unions should be 
    - Multiple objects from multiple label types
    - Also need to know who has done an implementation of these MIBs.
    - Bert Wijnen: reaffirmed that need people to review mibs even if they are 
    not MIB doctors to ensure it represents model of technology as needed.
    - Kireeti Kompella: who reads the MIBs? - How do you make people read 
    MIBs? This is part of progress of the protocol the documents. We need 
    feedback to know if we are going in the right directions.
    GMPLS-based Recovery (Dimitri Papadimitriou)
    Dimitri Papadimitriou provided a status on these i-d's (the 
    terminology, analysis and functional specification are closed, the 
    signaling needs to pass through a thorough review after becoming a 
    working group i-d), also pointed out that these documents should be 
    submitted to the IESG for the Dec'03 milestone (as per charter).
    - Adrian Farrel: count of approx. 8 read the drafts, and no-one thought  
    that the four drafts content overlapped e.g. that four were too many - 
    authors will ask for consensus via mailing list.
    ASON Signaling Requirements (Jerry Ash)
    Jerry Ash presented an update status on the document (note: the ver. under 
    discussion is v04.txt) authors believe that the document is ready for WG 
    last call.
    - Adrian Farrel: asked for count of who read document double digits (more 
    than 12), and support for going to WG last call also shows double digits
    - Adrian Farrel: ask if there are any objections.
    - Jonathan Sadler: noted that the proposed definition of call segment is 
    still being progressed at the ITU (thus should add this 
    clarification in the document). 
    ASON Interworking (Lyndon Ong)
    - draft-ong-ccamp-3473-3474-iw-00.txt
    - Dimitri Papadimitriou: pointing to the penultimate slide, commented you 
    have identified issues, and on mailing list were identified issues, and the 
    authors have not responded to these issues. Proposing the RFC 3474 as an 
    "existing RFC", but what is rationale for the CCAMP WG to deal w/ it since it 
    has an informational status at IETF.
    - Lyndon Ong: it is there, and its tied with an ITU standard
    - Dimitri Papadimitriou: technically speaking the first issue we have to 
    deal with is the usage of TNAs, but do not see any real rationale for 
    introducing them.
    - Kireeti Kompella: issue I have is that we have an existing document, RFC 
    3473, which is by definition the baseline from which we are building on and 
    then there is no interworking issue. 
    - Kireeti Kompella (Question for CCAMP): do we want to interwork? Before we 
    go into technical issues, we need to answer question what do we do with RFC 
    3474? What is its exact status? and then do we look at it for 
    - Lou Berger: what is confusing me and is where do we start from: we have 
    two RFCs - we have a long history of having RFCs which are 
    informational, but there is a difference between a proposed standard and an 
    informational RFC. 
      Here we're using ITU as rationale, this is why we are having this 
    discussion. As info RFC 3474 is an ITU work, what we should be doing is 
    coordinating and ask what does it take to support it? Is the info RFC 3474 
    the only way for achieving these requirements? Do we have to support RFC 
    3473? The response is yes, since RFC 3473 has the standing here in CCAMP.
      He also wanted to know whether this work is representative of a number of 
    people in ASON, or is it the work of a few people looking to do things a 
    different way.
    - Lyndon Ong: ITU 7713.2 and RFC 3474 are tied to each other and they do not 
    represent a minority view. 
    - Bert Wijnen: Substantiated this point.
    - Lyndon Ong: Pointed out that this group could either start with what has 
    been defined already or start over. The latter approach is more likely to 
    produce divergence rather than convergence.
    - Deborah Brungard: this draft is missing consideration of backward 
    compatibility aspects with RFC 3473 - CCAMP WG needs to consider RFC 3473 
    compatibility, not just compatibility with info RFC 3474.
    - Bert Wijnen: CCAMP WG needs to identify to ITU any fatal flaws with info 
    RFC 3474, and work with them.
    - Kireeti Kompella: What will the IETF and ITU will if there is some 
    vendor with 5K implementations with the "fatal flaw"?
      He then observed that the discussion is taking far longer than he had 
    expected and asked that people at the mike should be the last and 
    further discussion clearly needs to take place on the list.
    - Malcolm Betts: the emphasis should be on need to move forward and the 
    definition of future capabilities.
    - Lou Berger: CCAMP WG needs to look at info RFC 3474 and identify the 
    flaws, and work on a standard ASON GMPLS solution here in CCAMP.
    RSVP-TE ASON (Dimitri Papadimitriou)
    - Lyndon Ong: disagrees with conclusion that the RFC 3474 is not 
    backward  compatible with RFC 3473, e.g. RFC 3474 does not require an 
    intermediate node to support RFC 3474. And that RFC 3474 does not 
    address all the requirements is immaterial, it was done at a certain time, 
    and new capabilities will need to be added.
    - Dimitri Papadimitriou: you say need convergence but the 3474 
    extensions do not address the needed functionality and the analysis 
    provided in the appendix of this i-d shows where the backward 
    compatibility issues are if this is used.
    - Kireeti Kompella: take to list to discuss technical arguments if RFC 3474 
    compliant or not, and if it meets requirements or not. Will need to 
    liaise with ITU
    - Lyndon Ong: need to take into account that this method is an already 
    agreed ITU standard so question is why diverge from the RFC 3474 
    - Kireeti Kompella: we also have to agreed on a standard from the IETF 
    side. Lets look at technical arguments on 3474, and see how to get to an end 
    MPLS Crankback (Adrian Farrel)
    - draft-iwata-mpls-crankback-07.txt. 
    Adrian Farrel gave a short status update
    - The draft needs to deal with the fact that there are not enough flag bits 
    in the Session Attributes object.
    - The authors need to define logical grouping of TLVs, remove the 
    unnumbered component link IF_ID TLV from this draft (because it is more 
    generally applicable).
    - Adrian Farrel: 
      ask who read the draft: good showing
      ask to become a WG document: no dissent
    - Kireeti Kompella: good support, should keep as separate document for now 
    although will probably be part of an ASON "boxed set" We need 
    feedback, Adrian will lead the discussion via mailing list.
    ASON Routing Requirements (Deborah Brungard)
    - Liaison statement to ITU-T
    - Zafir Ali: question if requirements are from service providers (and not 
    only vendors)
    - Deborah Brungard: yes, providers and vendors participate in ITU.
    - Kireeti Kompella: we will start with the requirements from ITU and 
    prioritize them 
    - Deborah Brungard: important to understand terminology and dialogue on 
    understanding requirements with ITU.
    - Kam Lam: will include G.7715.1 ? 
    - Deborah Brungard: yes
    - Kireeti Kompella: waxed philosophical about the advantages of 
    striving to attain a state of boredom in the CCAMP WG.
    Tunneling Protocol 
    - draft-bonica-tunproto-05.txt
    Not presented.
    - Adrian Farrel: Ron Bonica missed the submission deadline.
      This is now on our charter so we need to pay attention.
    Arthi Ayyangar - 
    - Discussed some issue with terminology - specifically the 
    over-loading of certain terms. She also talked about possible 
    strategies related to the duplication of work in this and - the next - 
    JP Vasseur - draft-vasseur-inter-as-te-01.txt
    - He gave a brief status/history of the draft - what charter item it 
    attempts to address, how long they have been working on it, etc.
    - Dimitri Papadimitriou: Wanted to know whether or not we would first 
    consider whether or not LSR PCS should be done before we consider how to do 
    - JP Vasseur: Suggested that this is a question, among others, for the 
    - Arthi Ayyangar: Pointed out that the discussion needs to focus on 
    requirements before focus on a solution.
    - Kireeti Kompella: Looking for a single document for both models of 
    signaling. He would also like this work to include applicability for each 
    different model.
    - Arthi Ayyangar: Please clarify what set of drafts are expected.
    - Kireeti Kompella: Provided a breakdown of the documents and the issues 
    with where the work might be done on each part of the set.
    - Adrian Farrel: Can we have a date by which the combined draft will be 
    produced? He would like the groups involved to take some time this week to 
    get started.
    - JP Vasseur (with good grace): January 16th 2004
    - Kireeti Kompella (summarizing):
      Should we have inter-area and inter-as as one draft and include both 
    solutions and show when applicable the different solutions for 
    different scenarios? -> yes
      Should loose re-optimization go to CCAMP? It is related work. -> need to 
    discuss this among the chairs/ADs
      Should this item address both packet and non-packet? 
      -> yes
      Concerning PCS signaling need to discuss among chairs/ADs, and if 
    agreement to add in the charter, need for re-chartering, and then 
    address the technical aspects
    Communication of LSP Alarm Information (Lou Berger)
    He said they do currently have some issues. A key issue is that the 
    standard alarm information defined by Telcordia and ITU are mostly in the 
    form of strings.
    - Kam Lam: points to X.733/X.736 and M.3100, will discuss it offline
    - Kireeti Kompella: Might need to update charter before considering this 
    item, chairs and ADs need to discuss. Also, not too many read draft, need to 
    start thread on email list, need to get carriers to speak up.
    GMPLS Signaling for L2 LSP services ( Dimitri Papadimitriou)
    Dimitri talked about some work that they have recently started for L2SC in 
    GMPLS. This work does not include use of PW over PSN.
    - Chairs:
      - Ask who read the draft: 12 at least
      - Ask who feel it should be an item CCAMP should work on: 
        12 at least
    - Kireeti Kompella: Pointed out that this work is not in the CCAMP 
    charter and it may be difficult to add it because there is no focus in the 
    IETF for L2 services.
    - Kireeti Kompella: not in CCAMP charter to do 
    technology-specific work, need to discuss if it can go in charter. 
    Already have SDH and G.709.  And we need to check is there no other layer 2 
    specific work in other IETF groups, then probably could be in CCAMP
    - Dimitri Papadimitriou: point out that even if there are no layer 2 
    specific documents, RFC 3473 and GMPLS Architecture covers L2SC LSP 
    concept (in particular, ATM and FR). So this should equally be covered by 
    the existing charter.  He also asked what he would need to do to 
    strengthen the argument for getting this work accepted by the ADs.
    - Kireeti Kompella: Consensus is a powerful argument.
      We need to discuss this with the ADs before moving forward
    Component Link Recording and Resource Control for GMPLS
    Link Bundles (Zafar Ali)
    - Chairs:
      - ask who read the draft: 8 to 10
      - ask who feel it should become a WG document: 8 to 10 
    - Kireeti Kompella: concerns about what it is trying to fix. Need reason to 
    put this in ERO, so need to understand why we want to put this in the ERO
    - Adrian Farrel: would like to hear from providers on need to use this 
    before trying to adopt it. Take it to the list
    Requirements for time-bounded notification of faults
    (Richard Rabbat)
    - draft-rabbat-expedited-flooding-00.txt
    - Adrian Farrel: the discussion should be taken to the list in order to 
    agree on requirements before looking at solutions.
    - Kireeti Kompella: If one is to pursue the link-state 
    routing-based solution, then discussion on the OSPF and ISIS mailing lists 
    would be appropriate as well.
    *** Meeting in adjourned 


    ITU-T Study Group 15 Communications to IETF CCAMP Working Group
    GMPLS-based Recovery
    Requirements for Generalized MPLS (GMPLS)
    3473/3474 Interworking
    GMPLS RSVP-TE Signaling in support of ASON
    Crankback Signaling Extensions for MPLS Signaling
    ASON Routing Requirements
    Inter-region MPLS Traffic Engineering
    Inter-AS MPLS Traffic Engineering
    Communication of Alarm Information
    Generalized MPLS Signaling for Layer-2 LSPs
    Component Link Recording and Resource Control for Link Bundles
    Expedited Flooding for Restoration in Shared-Mesh Transport Networks