2.5.2 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-19

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  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-03.txt
  • - draft-ietf-ccamp-sdhsonet-control-02.txt
  • - draft-ietf-ccamp-gmpls-g709-06.txt
  • - draft-ietf-ccamp-gmpls-tc-mib-03.txt
  • - draft-ietf-ccamp-gmpls-te-mib-04.txt
  • - draft-ietf-ccamp-gmpls-lsr-mib-03.txt
  • - draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
  • - draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt
  • - draft-ietf-ccamp-gmpls-overlay-03.txt
  • - draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
  • - draft-ietf-ccamp-gmpls-ason-reqts-05.txt
  • - draft-ietf-ccamp-rsvp-te-exclude-route-01.txt
  • - draft-ietf-ccamp-gmpls-recovery-functional-01.txt
  • - draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
  • - draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt
  • - draft-ietf-ccamp-crankback-01.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

    timeCommon Control and Measurement Plane WG (ccamp)
    THURSDAY, March 4 at 0900-1130
    CHAIRS: Kireeti Kompella <kireeti@juniper.net>
            Adrian Farrel <adrian@olddog.co.uk>
    Group Admin
      Admin - Nothing much to say (in English anyway)
            - In Korean, however, the following was said:  "Jigeumbuteo CCAMP 
    meetingeul sijakhagesumnida".
      Agenda bash (5 mins) - No changes
      Status of WG drafts and milestones Adrian's slides showed that we do have 
    some draft congestion in the WG.
        - RFC editor queue
        - status of IANA for SONET/SDH Kireeti talked about an issue with 
    SONET/SDH IANA assignments
        - need a means to get early assignments. There is WIP to 
    accomplish this, and it is moving ahead.
        - future allocation of "experimental" values
    Marco Carugi talked about work in SG-13 (SG13 liaison).
      He covered topics, new study areas, timescales, objectives
      and status. They are also looking for people interested in   doing work in 
    these areas.
      An L1 VPN questionnaire and framework draft were attached to the 
      Tomonori Takeda talked about the technical issues and details of the 
      Monique Morrow had a couple of clarification for Marco - When will the 
    consent portion of the work be done in the ITU?
        Marco said that the different pieces of work were progressing at 
    different speeds. Some material is already embodied in 
    recommendations. The next SG13 meetings are in June and September.
      Dimitri Papadimitriou asked if the draft (l1vpn framework) provided in the 
    liaison could include a summarization (as conclusion) on the expected 
    GMPLS work for the CCAMP WG, this would clarify the intent of the 
    liaison in term of expected effort for the CCAMP WG
        Kireeti answered. If CCAMP's rechartering this month results in the 
    addition of L1VPNs to the charter, then a Liaison response from the IETF 
    will include this information, plus a request for a cooperative effort, 
    preferably along the lines of the ASON routing work, wherein the ITU-T 
    defines the requirements and the IETF does the protocol extensions.
      Alex Zinin said that we will have to make a decision at some point as to 
    whether or not we want to do this work here.
      Kohei Shiomoto said that the protocol for the L1VPN should be 
    developed at the IETF as long as it uses IP protocol. There are already 
    internet-drafts on GVPN and CCAMP is the best place to discuss it.
      Deborah Brungard said that there is work and some synergy and that we 
    should continue to work on this.
        Monique Morrow agrees that we should work on that.
        Marco added some comments that were not captured in the
        Malcolm Betts said he also feels that we should do this.
      Adrian took a quick poll and it seems as if nobody is against doing this 
      Kireeti reminded people to continue this discussion on the list.
    Lyndon Ong talked about work in SG-15 (3 liaisons).
      Liaisons were on ASON routing requirements, response to comments on Q14 
    for G.7713.2 and comments on the CCAMP ASON signaling requirements draft.
      Lyndon spent much of the time on the details of response to comments on 
    Q14. It seems that some of the differences in architectural models 
    revolve around "end-to-end" and "call segment" operating models.
      Kireeti asked for the reply by date.
        Lyndon did not have that.
        Steve Trowbridge said that the meeting starts on April 19th
      Dimitri had a question on the deadline. There is a deadline on G.7713 
    (April 2004), isn't there a similar deadline on G.7713.2 (since this is the 
    document to which convergence is expected) ?
        Lyndon said that he had not gone into that. He gave a reason, but this 
    was not captured in the minutes.
      Deborah said that the liaison for 7713.2 does not say any thing about 
        Lyndon said that they are still looking for a "meeting of the 
      Deborah said that there is an issue with G.7713.2 because of 
        Lyndon said that yes there has been a lot of discussion of 
    compatibility questions and requirements.
      Kireeti said that we should not discuss this here.
      Steve Trowbridge added some comments that were not captured in the 
      Kireeti asked the WG to take this discussion to the list and try to keep 
    that discussion on a productive basis.
      Adrian said that he wanted to recognize the efforts of the ITU folks in 
    this work.
    ASON Requirements and Solutions
    Dimitri Papadimitriou presented status of ASON Signaling
      The requirements were driven by last year's liaison from the ITU.
      The discussion slides proposed to defer to the GROW WG (cf. RIFT WG 
    item) concerning the (external) non-IP reachability issue since much 
    broader than just CCAMP GMPLS/ASON context
      After this meeting, Dimitri would like to re-spin the draft and have a two 
    week last call.
      Lyndon said he want to capture the requirement on "non-IP 
    reachability" - whether or not we will work on it here
      Kireeti said that we first need to understand importance of this and then 
    we can look to the ADs for guidance on handling this.  He also said that we 
    should take some time to work out what we want to say to the ITU when we 
    include the current draft.
    Dimitri Papadimitriou gave status ASON Signaling Solutions
    (draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.
      He would like feedback on whether or not the current draft deals 
    correctly with the session attribute object that encodes the long 
    call_id (alternatives were also proposed)
      His objective at this point is to try to have a document ready for last 
    call for the next IETF 60 meeting in San Diego
      Lyndon suggested that we might remove the comparison with G.7713 from the 
        Adrian asked if this meant that the interworking draft for 
    RFC3473/4 interworking was now obsolete.
          Lyndon said maybe, if interworking is removed as a 
    Lou Berger talked about Egress Control -
    draft-berger-gmpls-egress-control-01.txt -
      Original egress label control became explicit label control. This draft 
    attempts to capture the original intent.
      He wants to know if the WG feels that this is ready to be a BCP and what 
    the chairs think the next steps should be.
      Lou re-iterated that the purpose and scope of the draft is for 
    clarification. He does not see any value in adding to this intent or 
    combining it with other work.
      Adrian then took a poll and nobody objected to take this on as a WG item 
    (more than a third were in favor).
    Lyndon Ong went over status on ASON Routing Requirements -
      He includes in his presentation the Design Team's conclusions as to what 
    there is agreement about what's missing from GMPLS (delta), and what are the 
    areas on which there is no agreement about what's missing from GMPLS.
      Vishal Sharma asked if the three issues (slide 6) were already opened up 
    for discussion on the list, or would they be formally opened up with the DT 
    members initiating a discussion on these on the list?
        Lyndon Ong replied that a discussion had not been formally opened up yet 
    (although people were free to discuss/comment).
          Kireeti asked Lyndon to more formally open this discussion on the 
    mailing list.
      Vishal Sharma said that he supports this.
      Kireeti said he would like - after checking with the AD - that we 
    should take this work to the IS-IS and OSPF WGs.
        Alex Zinin said this is a good idea.
    Tunnel Trace
    Ron Bonica presented status on 
      The solution is very similar to Trace-Route but does not require that 
    each node in a tunnel supports TTL decrement.
      He gave a few examples as to how the idea in the draft will work in a few 
      There are a couple of outstanding issues:
      - trace requires a route to tunnel head end
      - integration with LSP ping.
      He would like to get the draft accepted as a WG draft.
      Yakov asked what SPs use today for tunnel tracing.
        Ron said that in some case people can use ICMP for MPLS.
      Yakov then asked if we could get a BCP on what people are doing.
        Ron asked if he should resubmit his earlier draft on this.
          Kireeti said that we do not want to decide that now.
    Protection and Restoration
    Dimitri Papadimitriou presented status on the work of the Protection and 
    Restoration Team - specifically:
      He gave estimates on the timing for each of the above drafts 
    (estimated completion dates).
      He outlined the changes to the e2e signaling ID (draft 4, above).
      He encouraged the WG to really read the documents and comment.
      Kireeti polled for consensus on the following:
        a) Analysis - last call? Some support, no objection
        b) Functional - last call? Some support, no objection
        c) Terminology - last call? Some support, no objection
        d) e2e Signaling - WG document? Some support, no object
       Kohei Shiomoto said that the e2e Signaling draft does not address the 
    misconnection issues raised in the mailing list.
         Dimitri answered that it is addressed in 8.3 of the draft.
           Kohei said that the misconnection issue does not happen only in the 
    P&R context but also in more general context and therefore should be 
    addressed in more general context as well.
             Kireeti said that the question should be continued to the 
    mailing list.
      People at the microphone were asked to take their questions to the list.
    Lou Berger presented an overview of work on Segment Recovery 
      He also talked about what still needs to be done (next steps), 
    including more usage scenarios, more explanatory text and see if the WG 
    will adopt this work.
      Arthi Ayyangar asked if the association object is required even if we are 
    only doing segment recovery (as opposed to e2e).
      Arthi asked why couldn't we extend the Detour Object to achieve the same 
    result. Kireeti asked her to take to the list.
      Richard Rabbat asked if this draft raised the same issues as the e2e 
    signaling draft in terms of misconnection.
        Kireeti replied that they did not know if there were 
    misconnection problems.
          Richard asked that the discussion about misconnections be moved to the 
    mailing list in the interest of time.
      Adrian polled for support of accepting this as a WG draft. There was 
    moderate support and no objection.
    Arthi Ayyangar talked about the status of the merged draft on 
    Inter-area/AS signaling 
      The draft currently represents a full merge - work is still required to 
    strip out redundant and unneeded text.
      She said that the authors encourage people to come forward with their 
    comments.  She would also like to see if there is interest in this work 
    becoming a WG document.
      Vishal Sharma said that the work should apply to general path 
    computation domains and GMPLS LSPs. In response to Arthi's question on 
    Slide "Outstanding Issues" (about whether detailed description of 
    various path computation algorithms should be part of this document or 
    separate document(s)), he supported the document being split into a 
    framework document, discussing signaling, and another document(s), 
    discussing the path computation mechanisms, since the latter do not need to 
    be standardized. In response to Slide "Outstanding Issues: Size of the 
    document" and for clarity, he supported the splitting of the 
    applicability statement into an independent document.
      Dimitri agreed on the subject of separating the document. In 
    addition, he questioned about the relevance of using the 
    LSP_Attributes to signal the signaling method for the 
    intra-area/-AS provisioning of the LSP. In particular, he proposed to not 
    include protocol procedures within examples/scenarios that makes the 
    document difficult to read.
        Arthi asked that Dimitri take his specific comments to the list.
      Kireeti said that he agrees that the document needs to be split - one as a 
    signaling and another (informational) to provide examples for path 
    computation. He also said that we need a separate applicability 
        Vishal Sharma then said that he would be happy to help with these 
    Vishal Sharma talked about work on Inter-area path protection
      He provided a brief overview of how it works, and showed how it 
    relates to other work in progress. He also listed the next steps.
      He emphasized that this is really a generic mechanism for diverse path 
    computation, and protection is one application of it, so the authors would 
    respin with a new name and emphasis to reflect this."
      Zafar Ali asked how this would work if there is a failure at the time 
    during which the backup path is being setup.
        Vishal replied that the solutions to this were, so far, not 
    discussed in the draft, but that there are several options.
        He then outlined some of the options. E.g. either default in such a 
    case to a sequential computation, and use XRO to exclude the link/node 
    where backup path setup failed, and retry the backup (and optimize both 
    primary and secondary later using the techniques in the draft). Or, set up 
    the primary and the backup again, using the techniques described in the 
        Vishal said they would be happy to add some discussion in the 
    document, and welcomed feedback on the list.
      Zafar asked how this work relates to PCS/PCE work.
        Vishal replied that it could actually be made use of by the PCS/PCE 
    approach, and could be viewed as complementary.
      Kireeti asked that further discussion be taken to the list.
      Vishal said he welcomed further feedback on the document.
      Dimitri asked why, knowing that the proposed approach works as 
    expected in the intra-domain case when the number of ABRs (where 
    computation can be executed at each stage) does not increase, this 
    approach is so focused on optimization (since it can't be achieved if this 
    condition is not met).
        Vishal clarified that the focus of the work is to propose a generic 
    mechanism to facilitate diverse path setup by communicating alternate path 
    info, with optimization a desired goal (for reasons explained in the 
        Vishal added that given the network model (where border nodes are not 
    assumed to have visibility in areas other than their own), the scheme was 
    not trying to be globally optimal.
        Vishal explained that in such cases some selection needs to be 
    performed at each stage.
      Kireeti asked that further discussion on this should be taken to the 
      Also, he said that Dimitri had a good point - we need to define 
    criteria on which any optimization is based.
      Kireeti concluded by saying that path protection and inter-area are both in 
    the charter, but that this document could only be considered for a WG 
    document after there was discussion about the document on the list.
    Control Pane Resilience, Hello Protocol and Graceful Restart
    Young Hwa Kim gave a presentation on Requirements for the Resilience of 
    Control Plane in GMPLS -
      He described the reasons why control plane resilience is needed.
      Zafar asked how control plane resilience is different from  anything else 
    in IP.
      Steve Trowbridge said that their is also some work in this area in the ITU 
    and he would try to get this in as a liaison as soon as possible.
      Kireeti said that this is an important discussion and there are a lot of 
    things to do. Specific topics should be raised on the list when 
    Lou Berger went over Extensions to GMPLS RSVP Graceful Restart
      He emphasized that egress restart is already covered in RFC3473 and this 
    work has no effect on that functionality. He gave a brief overview and 
    listed open issues.
      Next steps include merging with other restart drafts and seeing if this 
    work can become a WG draft.
      Arthi Ayyangar said that the text at the beginning of the draft seems to 
    talk only about the recovery ERO, although using the RecoveryPath one can 
    recover many objects besides the ERO. So the text should be clarified to 
    this effect.
        Lou asked if she would like to contribute text.
      There was a discussion on adjacent node restart.
      Arthi asked why adjacent node restart was an issue being addressed in 
    RSVP-TE. She pointed out that before this becomes an issue to be solved in 
    RSVP-TE, we would first need to check if adjacent node restart even works 
    for IGPs.
      The chairs then asked for other discussion to go to the list.
    Zafar Ali talked about Extensions to GMPLS RSVP Graceful Restart
      Kireeti said that he appreciated the honesty of the authors in 
    acknowledging other work.
      Nurit Sprecher asked about the relationship to FRR and similar issues.
        Adrian agreed that these were important issues and had been raised on 
    the list in recent days. He asked the authors to make sure that they cover 
    the points in the draft.
    Zafar then covered modifications to Hello procedures
      He wants to go forward with draft 1 above.
      Adrian polled and there was some interest and no strong objection.
      Kireeti said that this work cannot be informational if it has - or 
    proposes - changes to a standard.
      Zafar also wants draft 2 to be a WG document.
      Kireeti said that we need to take this to the list, but Zafar also needs to 
    socialize the work he is doing so that people may decide whether or not 
    this is work we want to do.
    Everything Else
    Emmanuel Dotaro gave status of Multi-region protection -
      He briefly covered changes since previous versions.
      He proposes that we may need to make changes to the charter to include all 
    of this work. In particular to include in the charter the complete set of 
    GMPLS mechanisms for integrated control planes, and not only 
    multi-layer recovery (as it stands today).
      Adrian suggested that the authors need to get more people involved in 
    this important work and revisit this later.
    Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs 
      He would like to have this accepted as a WG document.
      Adrian asked to hold off on this until after the OSPF talk below.
    Seisho Yasukawa
      He would like to have this accepted as a WG document.
      Regarding both drafts, Kireeti is not sure that this work belongs in this 
    WG. The decision is driven by the generality of its 
    applicability. If we do take it on, their needs to be a functional 
    specification (independent of IGP) as well.
      He asked that further discussion be taken to the list.
    The Following presentations were postponed as we ran out of time. Adrian 
    made a couple of brief comments as follows:
      Zafar Ali - Explicit Resource Control and Tracking
        This work concerns identification of component links in EROs and RROs.
        A small group is currently examining other issues concerning 
    identification of component links in all aspects of GMPLS. A draft is 
    expected soon. Please mail Adrian or the list, if you want to be 
    involved in this work.
      Lou Berger - Alarm Reporting
        This draft is stable and complete in the view of the authors.
        A quick poll showed some support for this being a WG document, and no 
    opposition. This will be taken to the 


    ITU-T Study Group 13 Communications to IETF CCAMP Working Group
    ITU-T Study Group 15 Communications to IETF CCAMP Working Group
    Requirements for GMPLS Signaling Usage and Extensions for ASON
    GMPLS RSVP-TE in support of ASON
    GMPLS Signaling Procedure For Egress Control
    ASON Routing Requirements Design Team
    Generic Tunnel Tracing Protocol
    GMPLS-based Recovery
    GMPLS Based Segment Recovery
    Inter-area and Inter-AS MPLS Traffic Engineering
    Inter-area Path Protection
    Requirements for the Resilience of Control Plane in GMPLS
    Extensions to GMPLS RSVP Graceful Restart
    Extensions to GMPLS RSVP Graceful Restart
    Node ID based RSVP Hello: A Clarification Statement
    Administrative Control of RSVP Hello and Graceful Restart Procedure
    Multi-region Protection
    Advertisement of TE capabilities in IS-IS
    OSPF MPLS Traffic Engineering capabilities
    Component Link Recording and Resource Control for Link Bundles
    Communication of Alarm Information