2.7.1 Common Control and Measurement Plane (ccamp)

Last Modified: 2003-05-21

Ronald Bonica <ronald.p.bonica@mci.com>
Kireeti Kompella <kireeti@juniper.net>
Sub-IP Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
Alex Zinin <zinin@psg.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
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)
  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
  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
  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
  operations of service providers.

In doing this work, the WG will work closely with at least the
other WGs and constituencies: TEWG, PPVPN, IPO, MPLS, IPORPR, ISIS,
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-07.txt
  • - draft-ietf-ccamp-lmp-09.txt
  • - draft-ietf-ccamp-gmpls-routing-06.txt
  • - draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
  • - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
  • - draft-ietf-ccamp-lmp-mib-06.txt
  • - draft-ietf-ccamp-lmp-wdm-02.txt
  • - draft-ietf-ccamp-sdhsonet-control-02.txt
  • - draft-ietf-ccamp-gmpls-signaling-survey-03.txt
  • - draft-ietf-ccamp-gmpls-g709-04.txt
  • - draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
  • - draft-ietf-ccamp-tracereq-05.txt
  • - draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
  • - draft-ietf-ccamp-gmpls-overlay-01.txt
  • - draft-ietf-ccamp-gmpls-recovery-analysis-01.txt
  • - draft-ietf-ccamp-gmpls-recovery-functional-00.txt
  • - draft-ietf-ccamp-gmpls-ason-reqts-02.txt
  • - draft-ietf-ccamp-rsvp-te-exclude-route-00.txt
  • Request For Comments:
    Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description (RFC 3471) (72105 bytes)
    Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions (RFC 3472) (49006 bytes)
    Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (RFC 3473) (91808 bytes)

    Current Meeting Report

    Doc status - Kireeti presented slides (could not keep notes on all)
    GMPLS signaling for SONET/SDH - RF Ed Q
    GMPLS Non-std SONET SDH features - killed
    GMPLS RSVP support for overlay model - authors to respond to list 
    ASON requirments for signaling - one more update prior to straw poll WG 
    last call
    Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
    Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG 
    last call
                                       - Number of docs stacked up based on 
    this doc
    OSPF ext in support of GMPLS - awaiting above
    ASON routing rqmts - Design team created, members, milestones and 
    to be posted to list
    LMP - security section needs work
    GMPLS recovery - Design team says ready for last call
    GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
    GMPLS architecture - waiting on normative refs
    GMPLS trace in RFC ed Q
    Framework for GMPLS-based control of SONET/SDH - Informational
    Several individual contribs and WG docs not covered. Would like to 
    progress the above mature docs.
    Alanqar    ITU SG15 Liaisons
    * Links to liasion statements in slides
    * Focus is ASON signaling protocol and routing extensions
    * Thanks extended to chair and invited experts
    * Snapshot of approved and under development stds
    * Signaling updates
            - G.7713 terminology alignment with G.8080
            - support for crankback
            - Call/connection separation
    * Comments on G.7713 solicited
    * No need to develop alternative solution
    * Routing updates G.7715.1
            - Goal is consent in Oct 2003 Geneva
            - OSPF ext for ASON
            - Potential use of PNNI
    * Addressing: signaling, control and management usage important
            - separate address spaces for control and management
    * Auto discover G.7714.1
            - Further investigation initiated
            - Focus on type A (trail overhead)
    * Arch for discover & control plane G.disc_arch
            - New scope/title for G.7716
    * Management framework - new doc created in Chicago G.frame
            - Goal of consent by May 2004
    No questions
    Kireeti - ccamp needs to formal liaisons
    * Presented by Jerry Ash
    * background, overview, issues presented
    * History has created need for better communication
    * Need to continue/ensure joint IETF/ITU-T working team
    * Intention of draft is not to repeat G.8080, but to address 
    additional GMPLS signaling requirements to support ASON.
    * Six broad areas of requirements
          - Support for soft permanent connection capability
          - Support for call and connection separation
          - Support for call segments
          - Support for extended restart capabilities during control plane 
          - Support for extended label usage
          - Support for crankback capability
          - Support for additional error cases
    * Ensure that IETF & ITU-T work jointly on requirements & protocol 
    extensions, and evaluate signaling extensions included in G.7713.2.
    * Another iteration and then WG last call
    * Progress signaling extensions
    * Routing is a seperate topic (from protocol extensions). Encourage joint 
    work between ASON experts and IETF routing experts.
    * No questions nor discussion
    * ccamp folks should work jointly with ASON experts for issues with 
    protocol extensions.
    * isis and ospf folks should work jointly with ASON experts on routi
    * Kireeti will float draft of liaison next week for comment
    * Could change title to "ASON discovery framework"
    * Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP 
            - includes port and component link types
    * G.8080 has transport (data) and control plane discovery with separate 
    addresses (draft says name space and not address?)
    * Proposed considering draft as WG document
            - A number of people had read this draft
            - not a broad consensus in support of this proposal
    * Lyndon Ong - Good doc, need to resolve decoder ring comments.
    * Jonathon Saddler - WG23 doc from ITU-T Chicago discusses some of these 
    * Malcom Betts - Question on control/data plane addresses in ITU 
    documentation. IP address in header, NHOP, PHOP have transport address.  
    Intent is to clarify usage, if already done then no need to repeat.
    Papadimitriou Protection and Recovery update
    * Presented by Dimitri
    * Effort positioning, status and timing over past 1.5 years
    * Scope: LSP protection, (pre-planned) LSP re-routing, dynamic LSP 
    * Not covered: local recovery, M:N end-to-end LSP prot., crankback (ref. to 
    * Summarized comments received
    * Proposed acceptance as WG document
            - consensus was that this is ready
            - Kireeti - take to the list
    * Discuss the extra traffic concept in a list thread
            - Dimitri will propose text to clarify this
    Farrel     draft-iwata-mpls-crankback-06.txt
    * Adrian Farrel presented
    * Has been around for several years and this version is a major re-spin
            - May be more complex than single node/interface
            - Objective is to fail back to some intermediate point (e.g., 
    region boundary or loose route identified node)
            - Requirement from ASON ITU-T
            - New co-author, Arun Satyanarayana
    * Summarize major changes in slides
            - long list of TLVs, but no adivce on which to include and when
    * Wanted to start thread on list re: remaining issues - some very thorny
            - session attribute bits (all would be used by this draft)
            - too many TLVs, need to confirm all are actually required
            - right place to handle unnumbered bundles
            - Is this the right approach, or should RRO be used?
    * Feedback solicited, resolve open issues
    * Add pointer from ASON signaling since it is long (different from slide 
    * Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
            - decide on approach (TLVs vs RRO) and with new charter decide on WG 
    * Dimitri - What is the basic set of TLVs needed and then address larger 
    * Adrian - What is needed is implementation dependent. Need input from 
    other service providers.
    * Kireeti: relate this to multi-area, multi-AS documents since a primary 
    application is setup failures in multi-region.
    * Adrian: Need more explicity requirements from te-wg on crankback 
    * Presented by Young Hwa Kim
    * Summarized survivability of control channels and neworks(from G.807)
            - assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN 
    * Stated problem as no provision of protection features in current GMPLS 
    control plane
    * Summarized requirements and functions for resilience of control plane
            - e.g., primary and secondary on separate fibers (shown in 
    * Next steps: proposed refine/complete requirements, protocol 
    specification, WG document in 2003/2004
    * Aboul-Magd: Are control channels visible to LMP? Why are current 
    control plane methods not sufficient? What are the deficiences?
    * Kireeti: Control plane is an IP network, not trying to redesign IP 
    resiliency. Are some issues: is graceful restart sufficient? Need to 
    convince WG that there is a problem to resolve. Do this on the mailing 
    * Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba 
    network does.
    * Malcom Betts - Control plane relies on IP network resiliency. G.8080 has a 
    number of resiliency considerations listed.
    draft-rabbat-optical-recovery-reqs-00.txt et al
    * Summarized changes
    * Solicited feedback
    * Kireeti: Had requirements from te-wg, keep this as separate doc, start 
    thread on mailing list
    * Draft stable, proposed adoption as WG draft
    * Need more discussion on WG list
    * soumiya-lmp-fault (not on agenda from Bonica)
    * How we reduce message overhead slide
    * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include 
    acknowledgement messages when assessing complexity.
    * Adrian: arrows on lhs (signaling) indicate a pair of messages for 
    * Kireeti: Was discussion comparing signaling message vs sending 
    flooding messages. Signaling is often faster (contrary to stmt that it is 
    slower). Flooding has a hold down timer aspect, but signaling is faster. 
    Issue with using LSPs for flooding since they are link local - seems 
    redundant with IGP (OSPF, IS-IS). Usurps LMP for different purpose. 
    Important point is that flooding is slower, but fewer messages as 
    compared with signaling.  Should discuss further on list. Concerned about 
    resolving problem of flooding already solved in GP.
    * Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and 
    routing. Don't understand why there is a need for this.
    * Jonathon Saddler: Concern that message indicates a fiber cut and not 
    messages for each affected LSP. A: Protection algorithms expect 
    knowledge that nodes know this mapping at a protection point. Issue is that 
    nodes may not know this mapping when multiple levels of indirection 
    exist. Presenter requested feedback on the list.
    * Bonica: Take further discussion to the list.
    * Presented by Shimoto
    * Brief overview of draft for shared mesh restoration
            - protecting LSP resource is reserved, but not 
            - extra class LSP can use this unused restoration capacity, which is 
    preemptable when needed for restoration (expected to be rare 
            - problems: advertise available resources, LSP indications and 
    preemption in signaling, prevent unintended connections, also protect 
    * Discuss comments from mailing list
            - can do using existing priority mechanisms where extra class has 
    lower holding priority than restoration LSP
            - complexity
            - soft preemption (not addressed in this draft)
    * Solicit comments/feedback
    * Proposed accepting this for ccamp wg
    * Dimitri: Question re: soft preemption as document or charter? A: 
    Propose adding to charter.
    * JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in 
    this draft. Q: Are you aware of draft on soft preemption? A: No. Q: What is 
    to be done with existing mechanisms?
    * Kireeti: Can be achieved with current mechanisms. Discuss on list. 
    Proposed action was for Dimitri/JP Vasseur to describe on list how this can 
    be done using existing mechanisms and Shiomoto to identify what is 
    * Presented by Deborah Brungard
    * Address requirements in GMPLS ASON presented earlier
    * Backward/forward compatible with GMPLS
    * Agnostic to network UNI implementation
    * Call/connection separation objects simply forwarded and not 
    * Described proposed mechanism for call/connection separation in detail
    * Summarized other additional ASON functionalities
    * Next version - add crankback signaling and call segments
    * Solicting feedback
    * Lyndon Ong: Requesting interpretation of "backward 
    compatibility" 7713.2 interpretation is to carry an object if is not 
    * Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T 
    liaisons and then decide how to progress this document.
    * Presented by Zafar Ali
    * Explicit Resrouce Control and Recording
            - Unbundled or bundled TE link type
            - Focus is case where component interface cannot be inferred from 
    label value
    * Current spec supports unbundled case for LSP splicing uni- and 
    * Can support bundled case by specifying component ID for LSP splicing
    * Cannot support bundled case for LSP splicing when forward and 
    backward component IDs are different in bi-directional
    * Propose optional interface identifier ERO subobject to address this case
    * RRO with label recording
            - could use to signal label values used within the bundle
            - cannot currently identify component interface used withing 
            - proposed solution is interface identifier RRO subobject, 
    similar to above
    * Propose accepting this as WG doc
    * Kireeti: Missing element in taxonomy (matrix) of these approaches not 
    sufficient for WG adoption. Understand RRO case. What is motivation for 
    ERO? A: Could have case where component links are different where 
    upstream and downstream differ. Bundle draft says that up- and 
    down-stream can differ. Q: Why don't the local nodes assign this (and 
    communicate selection in RRO). A: Consideration is on egress 
    specification of component ID. Don't understand resistance.
    * Kireeti: Post rationale to the list, beyond missing support in 
    taxonomy/martix for both RRO and ERO cases. If agreement, then can 
    * Swallow: Provider feedback is to keep up- and down-stream on same fiber 
    * Dimitri: Can provide examples for RRO, but believes there will be few for 
    ERO. Please expand compatibility statement in the last section.
    * Resource Mapping for GMPLS with Heterogeneous Interfaces
    * Problem: Label format for optical interface defined, but specific 
    mapping rule is not
            - Identify fiber, waveband, and lambda labels
    * Issue -1
            - Need aggregation for sharing in 
            - Support mechanism similar to label stacking in electrical 
    domain for optical interfaces
    * Issue -2
            - Logical resoure aggregation at switching interface - mapping, 
    aggregation (examples given)
            - Miscellaneous other issues (unnumbered links, bundling, SRLG 
    mapping, signaling, routing)
    * Is proposal acceptable to ccamp WG
    * Kireeti: Some routing and signaling defined in hierarchy draft. Here, 
    FA-LSP adverstises aggregate into IGP. Asked presenter to state why this is 
    needed on the mailing list.
    * Presented by Xiaoming Fu
    * A Proposal for Generic Traceroute Over Tunnels
    * A few issues with current GTTP draft
            - each hop supports GTTP
            - UDP issues: ports could be blocked by some ISPs, TTL=1, msg 
            - Reverse trace may not traverse same tunnel
    * Summarized potential solutions described in draft based on NSIS
            - Based on two-layer NTLP and NSLP NSIS protocol model
            - Can reuse TCP and SCTP to deliver trace messages (address 
    firewall issue)
            - NSIS discovery finds next (NSLP?) hop and uses traditional 
    traceroute between NSIS-enabled nodes
    * Should issues & concepts be considered in traceroute/GTTP design 
    * Bonica (as individual contributor): Q: Does probe sent to 
    destination visit intermediate nodes forward or backward? A: Still 
    investigating. Q: Would have to use alert? A: No, signaling can used 
    without routing alert. Should discovery of next hop be separate from 
    signaling. Q: Is trace control or data plane? A: NSIS direction is 
    discovering data path. Q: Will intermediate routers pass w/o change? A: 
    Yes, traditional traceroute does this.
    Chairs     Wrap up
    * See you in Minneapolis.
    * All presenters send slides to bonica and 


    None received.