IETF 64 – Vancouver, November 2005 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 Traditional Transport Network Control through Network Management System NMS Client A Client B TNE 1 TNE 2 TNE 3 TNE 4 TNE 5 TNE 6 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 Transport Network Control trough Management and Control Plane Management Plane 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 Client A Client B TNE 1 TNE 2 TNE 3 TNE 4 TNE 5 TNE 6 Generic Transport Links Transport resources statically allocated by NMS NMS-TNE Control Communication Transport resources dynamically allocated trough Control Plane Control Plane (Routing+Signaling) entities Control Plane

IETF 64 – Vancouver, November 2005 Management Plane Transport/Data Plane 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 Management Plane and Control Plane relationship Control 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

IETF 64 – Vancouver, November 2005 Data Circuit Ownership Handover Between Management and Control Planes 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 1.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 2.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 Circuit ownership handover cases:

IETF 64 – Vancouver, November 2005 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 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 Additional slides – Solution Details

IETF 64 – Vancouver, November 2005 Management Plane to Control Plane Handover Operation XXXXX Management Plane Control Plane MP to CP handover signaling Data Plane Client AClient 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 Ingress TNE Egress TNE Detailed (timeslot level) circuit description data

IETF 64 – Vancouver, November 2005 Control Plane to Management Plane Handover Operation XXXXX Management Plane Data Plane Client AClient 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 Ingress TNE Egress TNE Control Plane CP to MP handover signaling

IETF 64 – Vancouver, November 2005 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 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 MP to CP – alternative handover procedure [1] NMS Data Plane Control Plane Client sideNetwork side Client sideNetwork side 1. MP2CP request: 1 2. Data plane lookup: Get output port & label from Input port & label 2

IETF 64 – Vancouver, November 2005 MP to CP – alternative handover procedure [2] NMS Data Plane Control Plane Client sideNetwork side Client sideNetwork side 3. MP2CP request,, from step 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 4

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