Current Meeting Report
Jabber Logs

2.7.1 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/20/2002

Ron Bonica <>
Kireeti Kompella <>
Sub-IP Area Director(s):
Scott Bradner <>
Bert Wijnen <>
Sub-IP Area Advisor:
Bert Wijnen <>
Technical Advisor(s):
Alex Zinin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe 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 ISP and SP core tunneling technologies.

CCAMP WG tasks include:

- Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc.

- Define signalling and measurement protocols that are independent of each other. This allows applications other than the signalling protocol to use the measurement protocol; it also allows the signalling protocol to use knowledge obtained by means other than the measurement protocol.

- Develop and define a set of protocol-independent metrics and parameters for describing links and paths that can be carried in protocols. These will be developed in conjunction with requests and requirements from other WGs (e.g., TEWG, PPVPN, etc.) to insure overall usefulness.

- Abstract link and path properties needed for link and path protection. Define 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 and measurement protocols, either separately or in combination.

- Define how the properties of network resources gathered by the measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS.

- Define the relationship between layer 3 routing protocols and the common signalling protocol for establishing and maintaining paths.

- Using input from the TE working group, ensure that the signalling and measurement protocols provide both the information and the control functions adequate to support the traffic provisioning and engineering operations of service providers.

In doing this work, the WG will work closely with at least the following other WGs and constituencies: TEWG, PPVPN, IPO, MPLS, IPORPR, ISIS, OSPF, and GSMP.

CCAMP Documents Joint with MPLS:




Under consideration:

- draft-fontana-ccamp-gmpls-g709-00.txt

- draft-many-ccamp-gmpls-framework-00.txt

- draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt

- draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt

- and draft-bonica-tunneltrace-01.txt to this section.

Goals and Milestones:
Done  Post strawman WG goals and charter
FEB 01  Begin discussion of the framework and the requirement documents for signalling and for measurement
FEB 01  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
APR 01  Submit Initial framework and requirement documents
Done  Submit WG document defining path setup portions of common control plane protocol
Done  Submit WG document defining common measurement plane protocol
MAY 01  Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG
  • - draft-ietf-mpls-generalized-signaling-08.txt
  • - draft-ietf-mpls-generalized-cr-ldp-06.txt
  • - draft-ietf-mpls-generalized-rsvp-te-07.txt
  • - draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
  • - draft-ietf-ccamp-gmpls-architecture-02.txt
  • - draft-ietf-ccamp-lmp-04.txt
  • - draft-ietf-ccamp-gmpls-routing-04.txt
  • - draft-ietf-ccamp-ospf-gmpls-extensions-07.txt
  • - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
  • - draft-ietf-ccamp-lmp-mib-03.txt
  • - draft-ietf-ccamp-oli-reqts-00.txt
  • - draft-ietf-ccamp-lmp-wdm-00.txt
  • - draft-ietf-ccamp-sdhsonet-control-01.txt
  • - draft-ietf-ccamp-gmpls-signaling-survey-02.txt
  • - draft-ietf-ccamp-gmpls-g709-01.txt
  • - draft-ietf-ccamp-gmpls-tc-mib-00.txt
  • - draft-ietf-ccamp-gmpls-te-mib-00.txt
  • - draft-ietf-ccamp-gmpls-lsr-mib-00.txt
  • - draft-ietf-ccamp-gmpls-recovery-terminology-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF 54 CCAMP Meeting Minutes
    Schedule rearranged due to technical difficulties.....
    Kireeti:  Can someone come up here and sing during the break? *)
    0935 - 0950
    Provided summary of updates to LMP draft.  See his slides for details.  
    Thinks we are ready for IESG last call. Summary of updates to LMP WDM 
    See slides for details. Ready for WG last call. 
    Bonica: initiate last call on list after meeting.
    LMP Test Sonet SDH draft. See slides for details. After changes, we 
    should solicit comments from list. We would like a WG last call 
    thereafter. Get a feel from the room?
    Kireeti:  Assuming that J0-64 format is removed, are there any 
    Bert: The base LMP document was intended for proposed standard. We got 
    pushback from ITU people stating that we should not be working on some of 
    this stuff, so we split it out to a separate document. Are we 
    intending on prop standard for this stuff?
    Kireeti: Yes, prop. Standards stuff.
    Bert: Are we on our proper turf? I would like ITU people to speak up on 
    this as well as review it. I don't want discussion during last call, want 
    resolution now.
    Speaker 1: Question RE: LMP. After this meeting I intend to start a 
    draft.  After reading LMP specification, I believe it has mandatory 
    configuration.  Are there security considerations.
    Lang: Yes, security considerations are mandatory.
    Speaker 1: I would like security to be optional.
    Bert: Security considerations may not be optional.  We can have some as 
    optional, but some mandatory security options are required. 
    Kireeti: It is mandatory to define security - how to run LMP in a secure 
    mode.  It is not mandatory to run LMP in a secure mode. Can you?
    Lang: That is correct, it can be run un-secure.  Ipsec is defined for LMP.  
    If you do not want to run IPSec, you can run it without. 
    Speaker 2: I am concerned about J0 encoding. It doesn't seem to be 
    consistent with ITU T.50 requirement. Printable ASCII characters in 
    particular might be an issue.
    Bert: Please pose question to mailing list.
    Ron: That way we will have record of conversation.
    Lyndon Ong(Cienna): My company is editing 7714.1 ITU document.  Will there be 
    any additional alignment with this?
    Lang: I think the 7714.1 document is more closely related to bootstrap 
    document, and I would lke to discuss this in next part of 
    Lyndon: This is now taking LMP and LMP-WDM that are tech specific. Are 
    there any non-tech specific things that cannot be applied to both.
    Lang: The whole document can be applied to both.
    Kireeti: Is there any objection in ITU from letting IETF have this 
    document or will we dribble out requirements one by one?
    ITU leason: I cannot speak for all ITUT, but we need to socialize this 
    within the ITU.  
    There is work going on with regard to discovery in ITU 7714 that might need 
    to be aligned.  
    However, I will try to get discussion going on rapidly.
    Dmitry P:  There may be issues with the way the messages are encoded. 
    Kireeti:  We are not talking about discovery; test messages. Documents were 
    separated so that we can work issues doc-by-doc.  Good to get ruling for 
    each document. The typical issues with using J0 etc... has rules for how to 
    use this.  Make clear that that some issues are about before service 
    Speaker 5: 7714 issue: if they do the same thing, then why define two 
    documents for this?
    Lang: There may be overlap between next document, but not here.
    Speaker 5: Need to be clear about what the overlaps are.
    Lang: Bootstrap document (next doc), the intro describes why the doc 
    Prev. document is defined in LMP base document. If you disagree, let me 
    LMP Bootstrap document. See slides for details. This is not WG 
    document. Would like technical comments on list.
    Dmitri: Could you comment on applicability of incompatibility with other 
    Lang: The point to make is the information exchanged is the same as that for 
    the LMP protocol. There is no new information exchanged.
    Kireeti: We need to continue this on the list (ITU input) on how we move 
    these documents forward.
    Kireeti - CCAMP 55 WG status.
    Kireeti: Is there any problem with sending GMPLS framework to IESG as 
    Bert: I reviewed this doc a while back, and question is that 
    non-standard extensions are detailed here. This seems strange to publish a 
    document that suggests a way of signaling things without a document being 
    somewhere that details the specifics somewhere. 
    Dmitri: We have been looking for comments RE: 
    pointers/document to fulfill your query. I think it is unfair to 
    continue without filling these requirements. When I sent comments on the 
    list, I asked people to provide pointers. If people would like to 
    continue, please send pointers ASAP.
    Kireeti: As a fallback, what are we going to do if no docs are 
    Bert: Throw it into the garbage.
    Kireeti: Unless we get pointers, this goes in the can.
    Kireeti: One thing has been asked about is changes to the charter. We want to 
    make changes to the charter. Please send us suggestions. Few 
    additions: inter-area (within AS domain),  
    Protection/restoration, optical VPN.  This will be discussed partially 
    during SUB-IP meeting, but approval of charter changes come from IESG. 
    JPV: Question about the charter. Will signaling between computation 
    server and client are part of the charter, or do we need to add?
    Kireeti: The current charter does not explicitly have this. This is part of 
    the charter extensions we are asking for. 
    JPV: This can be used in other areas.
    Kireeti: Don't go there. If it is in the charter it is, if not then no. 
    Need to make sure this is in the charter. 
    Ron: I will send out an update on the charter additions (proposed) to the 
    mailing list.
    Ashok - Interoperability draft.
    Kireeti: FEC change and TSPEC changes are orthogonal to GMPLS. These are 
    issues for RSVP.
    Bert: These are separate documents. Do this in RSVP.
    Lou:  Spec. requires TSPEC. Lets talk about this offline.
    Kireeti: Okay. I want to talk about some implementation 
    recommendations. How are these published?
    Bert: Implementation recommendations are fine to either publish as BCP or 
    Informational.  I am worried about the limited set of 
    specifications/issues and that they are captured. 
    Kireeti: Generic RSVP things are already specified (according to Lou). Lets 
    talk about this offline to see where changes are required. Define what 
    issues are, how are they specified. Do this offline.  Should we add 
    recommendations to implementation survey as an appendix?
    Bert: Whichever.
    Lou: These look like guidelines to implementations. This is usually done 
    outside of spec. done as BCP/Info.
    Kireeti: Question is where to put it. 
    Lou: Seems like this is not a BCP. 
    Kireeti: Too early to say that these include "best" practices. Looks 
    informational. Need to talk with Lou about remaining issues. 
    Tom Nadeau did a presentation on the discussions regarding the GMPLS MIBs at 
    the Sat MIB Meeting.
    * how Saturday meeting affects the GMPLS MIBs?
    * issues for CCAMP: how to represent SONET (i.e. longer) labels
    * proposed solution on label/index given
      Tom asked for feedback from the working group on this proposed 
       type field + octet string
       goal is to support longer labels
    * Comment by Kireeti to rename 
      Link Bundling MIB to TE-LINK-MIB.
    (No questions on presentation).
    Nadeau: MIB overview presentation
    Dora: MIB discussion. 2 issues.
    Tom: SNMP is just another management interface, and like any other tool, it 
    needs to be used appropriately. Otherwise, you will have scalability and 
    provisioning issues.
    Kireeti: Lets have a discussion on the list for all of these things.
    Bert: Discussion going on in IESG/SNMP community. Been hearing that 
    people do not want to use SNMP for configuration.   However, I will defer to 
    the WG for guidance on this. We need discussion on this issue, in 
    particular from operators.
    Kireeti: We should take this to the mailing list. 
    Protection/Restoration Team: 
    Kireeti: I suggest that you kick off a discussion so that people can pick on 
    points that might be controversial. We need to do this before we make this a 
    WG document.  We need to take this into account.
    Dmitri:  We took existing protocols and analysed them.   What I have said is a 
    consolidation. I think we are fine with the scope. We need to focus on the 
    Kireeti: We need to make sure there is a consensus on your cut off that it 
    was reasonable.
    Bonica: Tunnel trace draft. See slides.  Is the requirements draft ready for 
    WG last call.
    Monique:  How is this going to relate to LSP Ping?
    Ron: When you discover a tunnel, GTTP invokes LSP ping.  There is one open 
    item: if the LSP is supported by an IP/IP tunnel. LSP Ping will not tell you 
    Kireeti: Are there any comments from anyone else?  The requirements 
    document is a WG document. Can we have a show of hands for support of GTTP 
    proposed solution as WG document?  We have a small consensus in favor of 
    this. Go back to mailing list to confirm.
    Dmitri: Draft.
    Dmitri: When you increase the scope of what GMPLS may cover. We need to 
    handle the limited complexity here. This is what we have worked on.   We 
    need to handle optical/PSTN. 
    Kireeti: Lets not make this a WG document until discussion on the list.


    WG Document Status
    ITU-T Study Group 15
    GMPLS for Multi-Region Networks
    LMP Draft Updates
    GMPLS Interoperability Test Event
    MPLS MIB Review Summary (Applicability to GMPLS MIBs)
    MPLS & GMPLS Control and Management - 2 Issues
    Protection & Restoration Design Team
    Tunnel Tracing
    GMPLS Signaling Support for the Overlay Model