2.7.1 Common Control and Measurement Plane (ccamp)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-20

Ronald Bonica <ronald.p.bonica@wcom.com>
Kireeti Kompella <kireeti@juniper.net>
Sub-IP Area Director(s):
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Sub-IP Area Advisor:
Bert Wijnen <bwijnen@lucent.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 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.

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
JAN 03  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-04.txt
  • - draft-ietf-ccamp-lmp-07.txt
  • - draft-ietf-ccamp-gmpls-routing-05.txt
  • - draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
  • - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
  • - draft-ietf-ccamp-lmp-mib-04.txt
  • - draft-ietf-ccamp-lmp-wdm-01.txt
  • - draft-ietf-ccamp-sdhsonet-control-02.txt
  • - draft-ietf-ccamp-gmpls-signaling-survey-03.txt
  • - draft-ietf-ccamp-gmpls-g709-03.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-01.txt
  • - draft-ietf-ccamp-tracereq-00.txt
  • - draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
  • - draft-ietf-ccamp-gmpls-overlay-01.txt
  • - draft-ietf-ccamp-gmpls-recovery-analysis-00.txt
  • - draft-ietf-ccamp-gmpls-recovery-functional-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

    Current Meeting Report

    IETF 56 - CCAMP
    Kireeti: WG status
    Short overview on status of WG documents as listed on web page.
    - framework for sonet/sdh control draft ready for LC? -> unclear
    - LMP MIB to Last Call?
      Bert asked for checkup
      Authors will provide new version and then last call on mailing list
    - non-standard sonet/sdh extensions? -> no interest in room
      Bert Wijnen: There is still no document describing what exactly is 
    signaled. If that is not provided, this draft should go to wastebin.
      **no referenced document**
    Wesam Alanqar: ITU liaison report
    ITU-T SG15 update to ccamp. This presentation has also been sent to the 
    mailing list.
    3 liaison statements exist: ason routing, discovery, 
    IETF routing experts are invited to come to next ITU meeting.
    Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based 
    After 1 year of work: terminology starts to be widely adopted, analysis i-d 
    still too largely scoped.
    Still needs to be covered: bulk lsp recovery, reversion (switch back)
    Next steps:
    next report April 03, func spec ready for LC
    Functional spec to be ready for LC *in April'03*
    protocol spec expected to be ready in July 03
    Should the terminology doc become PS?
    - AD will check whether it should be informational or PS
    Peter Czezowski: recovery requirements, fault notification protocol and LMP
    Presenting 3 drafts and changes to them:
    The first 2 drafts believed to be ready. There is running code for the 
    third draft, but is there any interest?
    Comments are requested from mailing list.
    George: Changing pt-to-pt protocol to a flooding protocol is more than just 
    adding a message. It results in a different implementation model for LMP.
    Kireeti: Don't start by modifying LMP, first look into problem and 
    requirements. Need mailing list discussion whether LMP is right.
    Alex: It took several net meltdowns to learn how to do flooding right.
    Dimitri: draft-lang-ccamp-lmp-bootstrap-03
    Changes: modified J0/J1/J2-16 string to fit within 80 bits, added layer 
    adjacency discovery
    Next steps: believes all technical issues raised on the mailing list 
    solved, accept as wg doc?
    Is this a worthwhile LMP extension (apart from questions about format 
    Kireeti: needs discussion on list
    Jonathan Sadler: mechanism worthwhile, encoding still has problems
    Dimitri: suggest to create document with common bootstrap mechanism, then 
    sonet/sdh specific doc, where sonet/sdh encoding specifics would be
    Jonathan Lang: is feature desired by community? find out before 
    splitting docs and put more work in it
    Question to room: ~7 think it's useful, nobody against -> take to list
    George: draft-ietf-ccamp-gmpls-overlay-01
    Question to room: "ready for WG LC?":
    ~20 yes, 0 no
    -> check consensus on list
    -> start WG last call after meeting
    Dimitri: technology specific routing extensions to GMPLS routing
    Changes: discussion concerning bandwidth encoding, section on 
    scalability and backward compatibility consideration.
    Falls within Sonet/SDH basket. Some assertions have been made on list, 
    addressed one-by-one in the presentation.
    Jonathan Sadler: need discussion on list instead of rhetorical 
    questions here
    A layering discussion ensued.
    Kireeti: need layer relationship document (refering to the mrn i-d)
    Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
    Kireeti: reasonable support, take to list
    Adrian Farrel: GMPLS MIBs
    3 drafts became WG drafts in June 02, nothing happened since.
    Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
      wait for MPLS MIBs republication and LC
      quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
      content additions, republish before Vienna
      chairs would like LC in August (but need WG feedback)
    Why in gmpls?
      think is ccamp charter item, increasing interest 
    (inter-AS/area), is mpls extension but is generalized and should be part of 
    Why needed?
      needed where path computation is not only in one place
      identification of new work items
      got useful feedback
      solicit input from providers
      look for convergence with JP's draft
      WG item?
    George: should talk about it in sub-ip directorate meeting
    Questions to room:
    ~15 have read the draft
    ~20 find it useful
    ~30 think it should become wg doc in some wg
    0 find it not ready
    Osama Aboul-Magd: a transport view to LMP
    Kireeti: What does control plane discovery mean?
             Is LMP + LMP bootstrap close enough to what this draft does?
    	 Very useful spec, provides "language translation".
    Malcolm Betts: progress this draft before LMP bootstrap draft
    Ron Bonica: generic tunnel tracing
    Requirements doc is stable, WG LC complete.
    Time to work on solution, IANA has assigned UDP port, new context object 
    Solicit feedback from implementers.
    Adopt as ccamp work item?
    Room poll: ~10 have read the draft -> need to take to list
    Ron (for Loa): MPLS and GMPLS change process
    Status: lots of lively discussion, topics:
    - is this merely a reaffirmation of IETF process?
    - what is the role of a liaison?
    - when all approvals are not obtained? Is there any alternative to the dust 
    Don Fedyk: need better understanding, common model/language
    Monique Morrow: ITU/IETF need to work together
    Jerry Ash: document describing liaisons?
    Kireeti: there already is such as doc (may be insufficient), separate from 
    Bert: liaison process is wider issue (not specific to this WG)
    Malcolm Betts: draft fine for IP applications, how about non-IP apps? How 
    can get those requirements recognized in IETF?
    Ron: requirements must be stated clearly to be understood by IETF WG
    Kireeti: Draft documents how ietf process works.
    	 The process may need a dust bin for bad ideas and another bin for "not in 
    IETF scope, but not really broken".
    	 It is not addressed yet how to handle stuff the IETF doesn't like.
    Alex: Need interest by IETF community to make things happen, same thing 
    applicable to anyone coming to IETF.
          People need to be convinced.
    Bert: subip area initially had problem with too many drafts, was fixed by 
    requiring problem statements
    Marten: Process is very mature dealing with submissions by 
    individuals, but not from other organizations.
    	I-Ds not suited to deal with peer standardization organization.
    	ITU can't do ascii diagrams or read through mailing list to gather IETF 
    	Need a way to apply IETF protocols to non-IETF problem.
    Kireeti: GMPLS work did step out of traditional ietf scope
    George: coopeation would work a lot better if clear requirements would be 
    communicated instead of sending in solutions
    	(even applies within IETF)
    Sharam Davari: another standardization organization should not have same 
    weight as an individual submission
    Ron: I-D should be evaluated on its merit, author irrelevant
    Kireeti: ccamp charter update
    - not done by WG consensus
    - proposed by chairs to AD, AD takes it to IESG/IAB
    Alex: correction: WG consensus *is* required but is not enough
    under consideration:
    - inter-area signaling and routing of generalized paths
       - crackback wrt inter-area
    - inter-as on hold until tewg produces requirements
    - explicitely put tunnel tracing in charter
    - routing extensions for Sonet/SDH
    - signaling for G.709 signaling
    - further LMP extensions
    - optical vpn *not* in charter
    - GMPLS MIB to WG LC in Aug 03
    - protection/restoration functional spec and protocol changes to WG LC by 
    Apr and Jul 03 (respectively)
    - tunnel tracing protocol to WG LC by Sep 03
    - set milestones for inter-area path setup when ratified as charter 
    need active discussion on list
    JP: combination of inter-area and inter-as is a good idea
    Kireeti: it is great if a common solution is available, but that is not 
    reason enough to put inter-as on charter
    Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for 
    Kireeti: ccamp should keep an eye on solution


    CCAMP Charter Update
    MPLS and GMPLS Change Process
    RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
    Generic Tunnel Tracing Protocol
    ITU-T Study Group 15 Update to IETF CCAMP
    MIBs for GMPLS
    Exclude Routes - Extension to RSVP-TE
    A Transport View to LMP
    Recovery Requirements, Fault Notification Protocol, and LMP
    Technology Specific Routing Extension to GMPLS Routing