NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Kireeti Kompella <kireeti@juniper.net>
Vijay Gill <vijay@umbc.edu>
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
Rob Coltun <rcoltun@redback.com>
General Discussion:ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: ftp://ops.ietf.org/pub/lists/
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:
draft-ietf-mpls-generalized-cr-ldp-04.txt
draft-ietf-mpls-generalized-rsvp-te-04.txt
draft-ietf-mpls-generalized-signaling-05.txt
Under consideration:
1. draft-dubuc-lmp-mib-02.txt
2. draft-fontana-ccamp-gmpls-g709-00.txt
3. draft-kompella-ospf-gmpls-extensions-02.txt
4. draft-many-ccamp-gmpls-framework-00.txt
5. draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt
6. draft-many-ccamp-gmpls-routing-00.txt
Feb 01 |
|
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. |
Mar 01 |
|
Build appropriate design teams |
Apr 01 |
|
Submit Initial framework and requirement documents |
May 01 |
|
Submit WG document defining path setup portions of common control plane protocol |
May 01 |
|
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 |
· GMPLS Extensions for SONET and SDH Control
· Generalized Multi-Protocol Label Switching (GMPLS) Architecture
CCAMP Minutes:
Milestones:
To dos:
- Make framework as working group document
- What to do about or extend the working group for
o Inter-AS signaling
o Optical VPNs
o G.709
o Measurement (routing, LMP, OLI, ?)
o MIBs
o Security (new design team)
Charter & draft updates:
Routing drafts are broken as "common" and "Protocol-specific"
ISIS will be dealt in the ISIS working group
OSPF will be dealt in the CCAMP working group
(EK: (mike goes dead, we can thankfully no longer hear kireeti babble))
Protection and restoration - ?
Hierarchical (multi-area) TE drafts
- Where will the protocol work be done?
o Wei - Can decide after the TE WG.
(EK: kireeti says protocol work belongs in ccamp; te-wg chairs agree.)
Update from the DT:
No presentation made.
GMPLS update (Lou):
(Generalized-signaling, RSVP-TE, CR-LDP)
Changes:
- More on the technology specific is separated and covered in length
- SONET/SDH is moved out to be included in another draft
- Issued joint CCAMP and MPLS WG last calls
Detailed changes:
- Technical error in LDP (?)
- Re-introduced Switching type in the G-PID
o To support multiple switching types on the same interface
- Administrative status information TLV is added
o To support state of the LSP (in Path/RESV) and
o To notify the status of an LSP otherwise
- Changes made in the scope of "control channel separation"
o Identification of data channels when the channel is not uniquely identified by control channel
o Handling of control channel failures that do not impact data channels
Next changes:
- Need more comments
- Ask IANA assignment for CR-LDP and RSVP-TE related information
- Some issues resolved
o Missing timeout
o Minor changes to
o G-PID change to avoid duplicity for SONET (?)
(EK: kireeti cant run powerpoint to save himself.)
Discussion:
3 weeks from today [i.e., by August 27] will close on the comments and move forward.
SONET/SDH (Eric):
GMPLS-SONET-SDH:
- This is the separated document from GMPLS signaling draft specific to SONET/SDH
- Flexible concatenation is NOT part of this document
- Mostly editorial, re-organizing, correctness etc.
- Appendices are provided for different implementation mechanisms supported using this draft
- Other modifications
o Improve the interoperability
o Etc.
- Targeted for informational RFC [not this doc, the new doc, see below]
- Move for IANA assignment
- Which appendices to be moved
o Contiguous concatenation
o Transparency (per byte)
o Virtual concatenation
o Signaling for non-std concatenation
o Appendix 1: Explained
Discussion:
Comment:
(EK: comment on if certain part should be on standards track or information)
[Clarification: the appendices that refer to items that are non-ITU-T standards get moved to another *informational* document.]
Concatenation conversion (Eric):
Problem:
- To avoid wastage of timeslots due to different concatenation mechanisms
Solution:
- SDH/SONET "Virtual Concatenation"
Proposed a contiguous concatenation (C) to virtual concatenation (V) conversion mechanism and extensions
- Realize ingress and egress aggregator
- Advertise the converting nodes using routing protocols
- Use signaling protocols to use this information to setup the path
Signaling:
- C->V is performed at the first converter and V->C is performed at the end converter (before the destination)
- 5 possible concatenation mechanisms can be negotiated
o CC e-to-e
o CC->VC
o VC->CC
o VC e-to-e
o ? [CC->VC->CC]
Discussion:
o Are there such converters available?
o Eric says at least two vendors have. He sees this evolving more and more.
o How many see this as useful function? - 10-15 (EK: 10)
o How many think this is should be done here? - 10
o How many think this makes sense? - 5 (EK: 8)
o How many think this does not make sense? - 2 (EK: 3)
o Why not in IPO?
o These are signaling extensions.
o Technology specific things should be in their respective groups. CCAMP is working on GMPLS
o What about VCs taking different paths?
o This does not include such paths
o (Marteen) This is a standard feature support (defined in G.707 and G.783). We should first focus on support for standard features before defining support for proprietary features. So this work should be in CCAMP.
Conclusion:
- WG chair's inclination is to make this as a WG draft. But since not many people understand these concepts let us take this to the mailing list before the decision.
G 709 (Dimitri): - Fontana-ccamp-gmpls-g709
What?
- Propose GMPLS based control plane for G709
- ITU-T G709 is getting standardized at ITU. Lets work on the control plane for it.
Why?
- G709 is a tera-bit tech for the future
- GMPLS solves the signaling mechanisms to control such a technology
Changes:
- G709 OTN is independent of the control plane
- GMPLS provides all the hooks without major paradigm shift
Propose a new G709 drafts similar to SONET draft
This is only about signaling extensions
Routing extensions for G709 are under consideration
Changes:
- Document name has changed
- Encoding type
- Signaling type
- GPID value list
- ..
Further changes
- Move features not covered by G709 in a dedicated draft
- OOS field description to be completed in appendix
- RMT/RNC to be adopted in RMT/RNC and RVC field
Conclusions:
- Propose to be working group document
- Features not in the document to be moved to extensions --
Kireeti - This should be driven more by what is in the ITU G709 document.
(EK: kireeti says that its not a vote; if its in g709 it should be in the document.)
[KK: Clarification: stuff that is not standardized by the ITU should be moved to another document.]
Decision - Consensus in the room is to adopt as a WG document. But will be taken to the mailing list before the final decision.
(EK: majority think this should be a wg document and that the signalling part belongs here.)
GMPLS TE MIB (Adrian)
Existing TE MIB (which is in the final stages in MPLS WG) is only for MPLS.
(EK: clarification this is the mpls te mib)
GMPLS extensions are provided in this draft.
This effort should not impede MPLS TE MIB progress.
This should belong in CCAMP.
Lot of interest on this work (by implementers, operators etc.)
Work includes TE and LSR MIBs for GMPLS
Updates will be provided next month
Make this CCAMP WG document
Discussion:
(AD) Bert: Make a MIB framework document with the gamut of MIBs to put them in perspective. Make sure that there will not be an overlap in these MIBs.
Decision - Wait for the overview draft.
(EK: bert before you extend or build on mpls mib document best to let that document go through iesg last call so that it stabilizes before you extend it. kireeti should we not make it a wg document until mplste mib settles...bert yes.)
GMPLS Architecture draft (Eric)
Was accepted as a CCAMP WG document
Gives GMPLS overview and provides how the building blocks are glued.
Changes:
- TOC, open issues, L2SC added etc.
- Many changes including scope of UNI, GASTN/GASON in the GMPLS context
Proposed sections:
- G709
- OLI
- Protection and restoration
o UPTO THIS IS IN THE CHARTER - What is below will be on consensus from the DT and further discussion.
- Multicast
- Inter-area TE
- Inter-domain
- VPN (OVPN) section
- Etc..
Discussion:
- (Jim Luciani) Make sure there will be no overlap on ASON work in the IPO group. - OK
(EK: lots of overlap with work thats being done elsewhere and work with person doing req documents from cienna on interarea work.)
- (Marteen) Wait for the ITU to come on consensus on OTN and Protection
- Make ASON relationship clarified in this document in terms of scope.
- Kireeti: Track what OIF and ITU work is being done. But we need to work on the signaling part should be done at CCAMP to move the work.
- No consensus on the draft status
[Editor to remove out-of-scope subjects. Draft status is "close to WG Last Call".]
Framework document (Yongwang Xu):
- Control plane is discussed from different perspectives
- What are the fundamental changes betn pkt and ckt based network ctrl plane design
- NW layering -- based on tech, BW mismatch, cost etc
- NW partitioning -- administrative (tech, geo, oper reasons)
- Overall -- reduce the tools to a common integrated control plane
Propose:
- Make this a WG document
Discussion:
- Greg: How is this different from what is being done in IPO? More number of authors and carriers
- Eric:
- ?: What about reliability of the control plane and bandwidth broker? --
Kireeti: Bandwidth broker is not in the charter. Reliability of the control plane will be discussed only after what is to be done is clear.
Consensus: Will take to the mailing list with the assumption that people are not sure.
(EK: kireeti: how many think we need gmpls framework document about 10 against 5.)
[KK: Yangguang disputes the numbers: 40 vs. 1 according to him.]
Framework on GMPLS based CP for SONET/SDH networks (Greg):
- Asked by many people to explain what are the problems with SONET using GMPLS
Discussion:
- Kireeti: Will be a WG document as informational.
LMP changes (Jonathan) -- Draft-ietf-ccamp-lmp-00.txt
- Remove CCId from TE link related messages
- Modified the LMP common header to include
o CCId specific messages
o The TE link Id for specific msgs
- Removed ChFailNack
- Removed LMPCapabilities TLV
- Next steps:
o Remove link MUX type
o Add on graceful restart procedures
Discussion:
- Why ChFailNack removed? -- Always the upstream node worries about it. So we can remove this msg without loss of info.
- What about tech specific mechanisms (for e.g., as specified by the OIF UNI for in band)? -- Since this involves protocol specific extensions, make a specific document.
- How many are implementing? -- 10 (EK: 15)
- How many carriers are interested in putting in the lab? -- None (EK: 5)
- How many think after the next rev there should a last call? -- 4
Wait for the next update and see if it is stable.
LMP MIB:
- Moved Link Summary retransmit values ...
- TE link table uses if id
Discussion:
- Will this be a WG draft? -- Accept as a WG draft
(EK: does this have to wait for mplste mib to move forward...kireeti views it as being 95% independant from the other mib so is available to move forward.
kireeti takes poll on if it should be wg document...20 for zero against.)
- Request: Send the dependency to the other TE components to the mailing list
OLI (Andre)
- Main objectives
o Enhanced fault detection/recovery for transparent optical XCs
? PXCs have limited detection mechanisms unlike SONET equipment
o Enhanced discovery of link characteristics for optical networks in general
? Reduce manual errors in configuring
o General requirements
? Simple protocol to report health
? Defined parameters
? Extensible to future techs like G709
? Reliable
? Secure
? No assumption on 1:1 relation between client and server
- Requirements
o Neighbor discovery
o Control Channel Management
o OLI synchronization
o Connectivity discovery
o Fault management
o Property discovery
Discussion:
- Angela: Is this required to run only OOB? -- Not necessarily. Could be used for opaque.
o Neighbor disc should be coordinated? - That was the intention
- Sham: Why this in IETF? -- Rough consensus to work in IETF.
This is because this work falls under measurement part of CCMP.
(EK: question: why should this work be done in ietf,no ip involved.....because it has an ip control plane thats why. randy: iesg goes around seriously..its here not because ip transport is being used to control the device, but that its carrying ip traffic....
kireeti: not enough that they are IP protocols but that they grow IP networks everywhere. hands on if we should be working on this or not..about 40 hands for 15 against.)
NTIP
- Added auto-discovery
- Reliable transport -- TCP - X
- Simple -- Assymetric relationship - ???
- CC Maintenance -- Keep alive
- Auto-dsc -- Supported
- Fault notification -- Supported
- Trace monitoring -- Supported
- Resynchronization -- Supported - X
- Fast notification -- Supported - X
- Issues with LMP-DWDM
o Assumes LMP exists
o Employs
LMP-DWDM
Discussion:
- Vijay: To have less new code in a box, I prefer LMP-DWDM.
- WG chairs: Move with LMP-DWDM if we move forward (i.e., if we are not stepping on ITU foot.)
- Osama: What is the procedure to follow up this formally with ITU.
o Randy: We have a formal channels
(EK: kireeti: needs duedilligence that we will move forward with lmpdwdm if we move forward with anything because the itu work might cover it making it not necessary to do this work at all.
question: how do we make sure this isnt work they are doing
randy: we have formal channels in place to ask the itu.
question: formal channels are in place...comment that it doesnt get used enough, more common that liason statements are used. randy: there are many other channels being used far more frequently then liason papers so nothing more formal or other channel is necessary0
Tunnel trace protocol:
- Protocol is completely stateless
- Refined PIO and TIO
- ?
- Issues:
o Works only for tunnels that have TTL expiration
o GTTP should support MTU discovery
Discussion:
- Consensus that this is a required concept.
- No consensus that this should a WG draft.
- Will be discussed on the mailing list.
(EK: kireeti: useful document? 20 yes zero no...is this document useful should this be a wg document 6 yes zero no.)
Link Management Protocol
Link Management Protocol (LMP) for DWDM Optical Line Systems
Optical Link Interface Requirements
GMPLS Signaling Extensionsv for G.709 OTN Networks
GMPLS Architecture
GMPLS Extensions for SONET and SDH Control
'draft-mannie-ccamp-gmpls-concatenation-conversion-00'
Generalized MPLS Signaling
Extensions to the MPLS WG TE-MIB to encompass GMPLS