1 / 15

Traditional Transport Network Control through Network Management System

GMPLS Signaling Extensions for the Transfer of Ownership of Label Switched Paths Between the Management and Control Planes draft-caviglia-mp2cpcp2mp-03.txt Diego Caviglia - Marconi Dino Bramanti - Marconi Nicola Ciulli - NextWorks Dan Li – Huawei Technologies.

gotzon
Download Presentation

Traditional Transport Network Control through Network Management System

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. GMPLS Signaling Extensions for the Transfer of Ownership of Label Switched Paths Between the Management and Control Planes draft-caviglia-mp2cpcp2mp-03.txt Diego Caviglia - Marconi Dino Bramanti - Marconi Nicola Ciulli - NextWorks Dan Li – Huawei Technologies IETF 64 – Vancouver, November 2005

  2. Traditional Transport Network Control through Network Management System NMS TNE 6 Client B TNE 1 TNE 2 TNE 5 TNE 4 Client A TNE 3 Generic Transport Links Transport Links w/ resources statically allocated to client A-client B circuit NMS-TNE Control Communication Transport connections over data plane are managed by NMS acting on each of the relevant TNEs No Control Plane is in place, all resources are owned by Management Plane IETF 64 – Vancouver, November 2005

  3. Transport Network Control trough Management and Control Plane Management Plane Control Plane TNE 6 Client B TNE 1 TNE 2 TNE 5 TNE 4 Client A Generic Transport Links TNE 3 Transport resources statically allocated by NMS Transport resources dynamically allocated trough Control Plane Control Plane (Routing+Signaling) entities NMS-TNE Control Communication A pool of transport resources is managed by NMS acting directly on each of the relevant TNEs Another pool of data plane resources are managed trough a distributed - GMPLS based - Control Plane IETF 64 – Vancouver, November 2005

  4. Management Plane and Control Plane relationship Management Plane Control Plane Transport/Data Plane Both control entities (MP and CP) own only their partition of networks resources and can only setup/tear down circuits that use their own resources Transport resources ownership means that related data records describing transport circuits reside within the owning entity and this means that an entity can only control circuits that it owns IETF 64 – Vancouver, November 2005

  5. Data Circuit Ownership Handover Between Management and Control Planes Circuit ownership handover cases: • Management Plane to Control Plane Handover: • A data plane circuit is in place and it is under control of NMS • Its ownership (i.e. its control) is moved from Management to Control Plane • For example: migration of traditional system to new Control Plane • Control Plane to Management Plane Handover: • A data plane circuit is in place and owned by Control Plane • Its ownership (i.e. its control) is moved from Control to Management Plane • For example: move an LSP into management Plane control to allow Maintenance without automatic Control Plane actions • The actual data plane connections stay untouched in both cases • Traffic continues to flow • Ownership handover is a transfer of control capability over a given pool of transport resources IETF 64 – Vancouver, November 2005

  6. Do we need this function? • Do we need to do this? • Support SPs who want to turn on the Control Plane • Do we need to do this without disrupting traffic? • Is it enough to do it in a maintenance period? • Can we do it with existing mechanisms? • Make-before-break on different path/resources assumes additional resources exist • Make-before-break re-using existing resources assumes that NEs know what is happening • Needs Control Plane or Management Plane “tweak” • Could/should we fix this in the Management Plane? • This would be just as simple • Proposed Control Plane solution is very simple IETF 64 – Vancouver, November 2005

  7. Summary of Proposed Solution • New Administrative_Status object flag • MP to CP • Indicate “in-place” resource allocation allowed • ERO identifies precise path and resources • CP to MP • Indicate “remove control plane state but leave data plane” • Assumes exchange of ERO/RRO information between CP and MP at ingress • Alternate solution flags the need for handover and has CP/DP interaction at each LSR to complete handover IETF 64 – Vancouver, November 2005

  8. Additional slides – Solution Details IETF 64 – Vancouver, November 2005

  9. Management Plane to Control Plane Handover Operation X X X X X Management Plane Detailed (timeslot level) circuit description data Control Plane MP to CP handover signaling Egress TNE Ingress TNE Data Plane Client A Client B • Data plane circuit connecting clients A and B is in place and it is under control of NMS • MP transfers circuit related information to CP entity at circuit’s Ingress TNE • Ingress TNE formats such info into a standard GRSVP-TE setup messaging, including all details allowing for a precise description of the LSP to be created at CP level (ERO and US/DS label). • GRSVP-TE signalling targeted at MP to CP handover is a standard PATH/RESV/RESV CONFIRM LSP setup flow, where a flag in ADMINISTRATIVE STATUS is set • TNEs involved in A-B circuit process the handover signaling, creating LSP records within CP, but not taking any action over data plane, where the actual connections stay untouched IETF 64 – Vancouver, November 2005

  10. Control Plane to Management Plane Handover Operation X X X X X Management Plane Control Plane CP to MP handover signaling Egress TNE Ingress TNE Data Plane Client A Client B • Data plane circuit connecting clients A and B is in place and it is under control of CP. • MP collects circuit related data and store them within its records • A standard GRSVP-TE LSP tear-down signalling flow, with a flag set in ADMINISTRATIVE STATUS object, is exchanged between involved nodes • TNEs involved in A-B circuit process the handover signaling, removing LSP records within CP, but not taking any action over data plane, where the actual connections stay untouched IETF 64 – Vancouver, November 2005

  11. Handover “H” Flag in Administrative Status object • This ID introduces a new flag, H flag, into the Administrative Status object (Admin_Status Object is defined in RFC 3473) • When H bit is set: • - in a GRSVP-TE LSP set-up flow, indicates that a Handover procedure for the transfer of circuit ownership between MP and CP is ongoing • - in a GRSVP-TE LSP tear-down flow, indicates that a Handover procedure for the transfer of circuit ownership between CP and MP is ongoing • When a H-flagged LSP set-up/tear-down signaling flow is exchanged between adjacent nodes, NO ACTIONS ARE TO BE TAKEN OVER DATA PLANE. • only a creation or deletion of LSP related data structures within CP or MP is performed IETF 64 – Vancouver, November 2005

  12. Alternative Way Of Doing MP To CP Handover • The solution presented so far requires a complete knowledge of the circuit details within MP • Required handover signalling has to include several optional objects • A minimal way to perform the MP to CP handover, not needing such details is presented in the following IETF 64 – Vancouver, November 2005

  13. MP to CP – alternative handover procedure [1] NMS Client side Network side Network side Client side 1 Control Plane 2 Data Plane 2. Data plane lookup: Get output port & label from Input port & label 1. MP2CP request: <src(node/port/label)> <dst> IETF 64 – Vancouver, November 2005

  14. MP to CP – alternative handover procedure [2] NMS Client side Network side Network side Client side 3 Control Plane 4 Data Plane 4. Data plane lookup & resource handover - Get output port & label from Input port & label - Compare output port & label with dst - Handover resources from MP to CP 3. MP2CP request <src>, <dst>, <Recovery Label> from step 2 IETF 64 – Vancouver, November 2005

  15. MP to CP – alternative handover procedure [3] NMS Client side Network side Network side Client side 6 Control Plane 5 Data Plane 6. MP2CP response 5. MP2CP response IETF 64 – Vancouver, November 2005

More Related