Last Modified: 2003-10-20
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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
CCAMP Working Group. 58th IETF Minneapolis Monday 10th November 2003 0900-11.30 CHAIRS: 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 Kireeti: 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 review) 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) ============================= Discussions: - 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) ======================= - draft-ccamp-ietf-gmpls-tc-mib-01.txt - draft-ccamp-ietf-gmpls-lsr-mib-01.txt - draft-ccamp-ietf-gmpls-te-mib-01.txt 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 supported. - Multiple objects from multiple label types - Also need to know who has done an implementation of these MIBs. Discussions: - 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) ============================================ - draft-ietf-ccamp-gmpls-recovery-terminology-02.txt - draft-ietf-ccamp-gmpls-recovery-analysis-02.txt - draft-ietf-ccamp-gmpls-recovery-functional-01.txt - draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt 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). Discussions: - 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) ======================================= - draft-ietf-ccamp-gmpls-ason-reqts-03.txt 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. Discussions: - 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 Discussions: - 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 interworking? - 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) ==================================== - draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt - 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 solution. - 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 point. 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). Discussions: - 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) ============================================ - draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt - Liaison statement to ITU-T Discussions: - 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. Multi-Area/AS/Region ==================== Arthi Ayyangar - draft-ayyangar-inter-region-te-01.txt - 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 - draft. 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. Discussions: - 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 it. - JP Vasseur: Suggested that this is a question, among others, for the list. - 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) =================================================== - draft-berger-ccamp-gmpls-alarm-spec-00.txt 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. Discussions: - 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) ======================================== ==================== - draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt Dimitri talked about some work that they have recently started for L2SC in GMPLS. This work does not include use of PW over PSN. Discussions: - 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) ======================================================= - draft-zamfir-explicit-resource-control-bundle-02.txt Discussions: - 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 Discussions: - 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 |