1 / 9

Jerry Ash AT&T gash@att

Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON) (draft-ietf-ccamp-gmpls-ason-reqts-04.txt). Dimitri Papadimitriou, Editor Alcatel dimitri.papadimitriou@alcatel.be. Adrian Farrel Olddog Consulting adrian@olddog.co.uk.

izzy
Download Presentation

Jerry Ash AT&T gash@att

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON)(draft-ietf-ccamp-gmpls-ason-reqts-04.txt) Dimitri Papadimitriou, Editor Alcatel dimitri.papadimitriou@alcatel.be Adrian Farrel Olddog Consulting adrian@olddog.co.uk Jerry Ash AT&T gash@att.com Lyndon Ong Ciena lyong@ciena.com John Drake Calient jdrake@calient.net

  2. Outline(draft-ietf-ccamp-gmpls-ason-reqts-04.txt) • brief review of problem statement & requirements for GMPLS signaling extensions for ASON • ‘you read the draft’ • changes from 01 to 04 version • next steps

  3. Problem Statement for GMPLS Extensions for ASON • problem statement • extend GMPLS signaling [RFC 3471/RFC 3473] • must meet FULL functional requirements of ASON architecture in GMPLS • provide call & connection management [G.7713] • must be BACKWARDCOMPATIBLE with current GMPLS RFCs • ASON architecture includes • automated control plane supporting both call & connection management [G.8080] • control plane applicable to different transport technologies (e.g., SDH/SONET, OTN) & networking environments (e.g., inter-carrier, intra-carrier) • multiple reference points of information exchange • between administrative domain & user • between administrative domains & areas within administrative domain • between controllers within areas

  4. Requirements forGMPLS Extensions for ASON • need to support ASON functionality in GMPLS • soft permanent connection capability • call & connection separation (includes calls without connections & adding/removing connections to/from calls) • call segments • extended restart capabilities during control plane failures • extended label association • crankback capability • additional error cases

  5. Changes from 01 to 04 Version • Introduction • refine reference point terminology (UNI, E-NNI, I-NNI) • ASON model distinguishes reference points (representing points of protocol information exchange) • between an administrative domain & a user a.k.a. user-network interface (UNI) • between administrative domains a.k.a. external network-network interface (E-NNI) • between areas of the same administrative domain & between controllers within areas a.k.a. internal network-network interface (I-NNI) • terminology section: add UNI term • review of author list

  6. Changes from 01 to 04 Version • Section 4: Requirements for Extending Applicability of GMPLS to ASON • definition of GMPLS [RFC 3473] compliant UNI: • ‘any User-Network Interface (UNI) that is compliant with [RFC 3473] is considered, by definition, to be a GMPLS UNI and must be supported’ • [GMPLS-OVERLAY] & [GMPLS-VPN] meet definition of GMPLS UNI • refine agnosticism criteria wrt UNI implementation for GMPLS support of ASON requirements • ‘support of GMPLS-ASON signaling protocol requirements must be strictly independent of & agnostic to any UNI & not be constrained by implementation specifics of the UNI [G.8080, G.7713]’

  7. Changes from 01 to 04 Version • refine interworking aspects of non-GMPLS address space/signaling mapping • end-to-end signaling should be facilitated regardless of administrative boundaries & protocols within the network • includes both GMPLS control domains & non-GMPLS control domains • I-D addresses ASON support within a GMPLS control domain & between GMPLS control domains • I-D does not restrict use of other protocols within a control domain • mapping of non-GMPLS protocol signaling requests & support of non-GMPLS address formats are responsibility of non-GMPLS control domain

  8. Changes from 01 to 04 Version • add Section 5: Backward Compatibility • following comment at IETF-57 & discussion on list • section defines backward compatibility wrt GMPLS signaling extensions for ASON: • in a network where some nodes support GMPLS signaling extensions for ASON & some do not, it must be possible to set up conventional connections per [RFC 3473] between any pair of nodes & traversing any set of nodes • use of GMPLS signaling extensions for ASON to set up calls must not perturb existing conventional connections • transit nodes in the path of a connection that do not need to participate in the new ASON-related functions must be able to pass call setup information onwards, unmodified • transit or egress nodes called upon to participate in the ASON-related functions, but not supporting the functions, must be able to reject calls by pre-existing GMPLS signaling mechanisms in a way not detrimental to the network

  9. Next Steps • no open issues at this point • authors feel this I-D is ready for WG last call • draft-ietf-ccamp-gmpls-ason-reqts-04.txt • progress GMPLS signaling extensions for ASON • progress GMPLS routing requirements & protocol extensions for ASON

More Related