When is it safe to send data in a network controlled by a GMPLS control-plane? Kohei Shiomoto Adrian Farrel NTT Old Dog Consulting

Executive summary  Data plane path is configured under control of signaling protocol running in the control plane in GMPLS networks.  Question is when it is safe to start data over the data plane path?  It is safe when control plane is “done” because XCs are programmed in a hop-by-hop manner from downstream to upstream as defined in the standard.  Is it fast enough? Or do we need to facilitate some other mechanisms?  Secondary issue is how to measure performance 2

Agenda  GMPLS  Control-plane for multiple switching technologies data-plane  Signaling protocol: RSVP-TE  Unidirectional and Bidirectional LSPs  Problem to be solved  When is it safe to send data?  Existing standard signaling protocol specification  Fundamental message processing rules  Note for bidirectional LSP  Implementation consideration  Performance interpretation  Performance optimization 3

GMPLS  Controls both packet-switching and non-packet-switching networks.  Creates data-plane path called label-switched path (LSP) by instructing to program XC at each hop. 4 t0t0 t2t2 t0t0 t2t2 t0t0 t2t2 t0t0 t2t2 N 1 : N 1 : N 1 : N 1 : Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber Switch (FSC) Label Switch (PSC) IP 16 IP 18 IP 32 IP 61 TDM Switch (TDM) Lambda Switch (LSC)

GMPLS for non-packet switching network  Control-plane is a separate IP network.  Signaling protocol runs in control-plane to establish LSP in data-plane. 5 Control plane Path 2-3 Path 3 Resv label 1Resv label LSR1 Port 2 Port 1 Controler 1Controler 2 Controler 3 Controler 4 Data plane D-plane switch LSR2 LSR3

Signaling protocol : RSVP-TE  RSVP-TE is the signaling protocol for GMPLS.  Path msg. from ingress to egress  Resv msg. from egress to ingress 6 Path Resv LSR ALSR BLSR CLSR D

Bi-directional LSPs  Both forward and backward LSPs are created in data plane by a single signaling exchange. 7 Path Resv LSR ALSR BLSR CLSR D

What does it mean to be “safe to send data”?  Data that is sent should be delivered to the LSP egress  Reliable data delivery  Data that is sent must not be delivered to the wrong egress  Security and confidentiality  In optical networks there are considerable safety concerns about turning on lasers to misconnected fibers 8

When is it safe to send data?  XC in data plane is set up under control of the signaling protocol.  Cannot send data before all XCs are correctly set up.  Is it OK to start sending data when the control plane completes its message exchange? 9

Fundamental message processing rules  A node should program XC before sending the Resv msg. to its upstream neighbor.  “The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message.” [RFC 3209, Section ]  Thus the ingress LSR can safely start to send data when it receives the Resv msg. (and programs its own XC). 10 Path Program XC Resv Program XC Resv LSR ALSR BLSR CLSR D OK

Note for bidirectional LSP  An LSR should program the XC for the backward data path before it propagates the Path msg. with Upstream-label obj.  “… An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing upstream label and propagating the Path message. …” [RFC3473, Section 3.1]  Thus the egress LSR can safely start to send data when it receives the Path msg. (and programs its own XC).  As before, the ingress LSR can safely start to send data when it receives the Resv msg. 11 Path /w UL LSR ALSR BLSR CLSR D Resv Program XC Resv OK

Note for bidirectional LSP (cont’d)  The ingress LSR MAY send a ResvConf msg. after it receives the Resv msg.  The egress LSR could use this to learn that the ingress LSR is ready to receive data.  Some implementations don’t support ResvConf  ResvConf is not reliably delivered 12 Path /w UL Program XC Resv Program XC Resv LSR ALSR BLSR CLSR D ResvConf OK

LSR D-plane switch Implementation consideration 13 Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber #1 Fiber #N Fiber Switch (FSC) Label Switch (PSC) IP 16 IP 18 IP 32 IP 61 t0t0 t2t2 t0t0 t2t2 t0t0 t2t2 t0t0 t2t2 TDM Switch (TDM) N 1 : N 1 : N 1 : N 1 :  After the label is decided in the control plane, the LSR programs XCs in data plane.  The control plane processors can be physically distinct from the data plane cross-connects.  There is a communication protocol operating between the control plane processor and the data plane switch.  The successful completion of control plane signaling cannot necessarily be taken as evidence of correct data plane programming.  How long it takes to finish programming XC depends on the implementation and the data plane switch type: packet, TDM, lambda, and fiber. Lambda Switch (LSC) Write SRAM, CAM for FIB (incl. ILM, NHLFE) Write SRAM for TST-SW Move mirror for MEMS-SW. Change temperature for TO-SW, and so on. Controler Protocol processing, resource management, etc. in control plane Communication overhead

Performance implications  Control plane (TC)  Protocol processing  Resource management  Data plane (TD)  Communication overhead b/w controller and switch hardware  Programming XCs in switch hardware  Some switch types or implementations can take too long to program XCs (TD too big)  Results in slow LSP setup 14 Path Program XC Resv Program XC Resv LSR ALSR BLSR CLSR D Program XC Slow! TD TC Program XC

Performance optimization – Suggested-label  Suggested-label object is used for optimization in programming XC.  Programming XC is pipelined with signaling  Nevertheless, even when Suggested-label is used, the ingress must not start to transmit traffic until it has both received a Resv and has programmed its own cross-connect (because suggested label value is rejected on Resv msg.)  “... an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream. ” [RFC3471, Section 3.4]  “... an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream. ” [RFC3473, Section 2.5]  NB: applicable to only forward data path 15 Path/w SL Program XC Resv LSR ALSR BLSR CLSR D Rejected SL & Re-program XC Resv Path/w SL Program XC Path/w SL Resv LSR ALSR BLSR CLSR D Resv Path/w SL Program XC

Further potential performance optimization  Signaling protocol could be used just for control plane resource management.  Programming XCs is done in parallel in data plane.  How do end points know when it is safe to send data?  It is possible to run a data continuity test emulating the client signal.  The ingress could send ResvConf when its XC is in place  Each LSR only forwards the ResvConf if XC is in place  Ingress still doesn’t know when it is safe to send  External mechanisms could be used for data continuity test depending on the client signal type, e.g., BFD or LSP Ping for MPLS networks.  Is this safe in optical networks? 16 OK (bwd) Path Program XC Resv Program XC Resv LSR ALSR BLSR CLSR D Program XC Data test (fwd) OK (fwd) Data test (bwd) Data test (fwd) Data test (bwd)

Further performance optimization (cont’d) Administrative Status object  Allows the ingress LSR put an LSP into "Testing" state.  This state allows the connectivity of the LSP to be tested without actually exchanging user data (no conflict with use for data – no accidental delivery of test signal to user)  In an optical system it would be possible to run a data continuity test (using some external coordination of errors).  In a packet network, a connection verification exchange (such as the in-band Virtual Circuit Connectivity Verification described in Section of [RFC5085]) could be used.  Once connectivity has been verified, the LSP could be put into active mode (using further Path/Resv exchange) and the exchange of user data could commence. 17 Path Program XC Resv Program XC Resv LSR ALSR BLSR CLSR D Program XC OK (bwd) Data test (fwd) OK (fwd) Data test (bwd) Data test (fwd) Data test (bwd)

Performance measurement  It is very important to be able to evaluate the performance of GMPLS technology and GMPLS equipment.  Measuring the control plane performance is not good enough  The important feature is when it is possible to start sending data  Need to measure time from first request to set up LSP until when it is safe to start sending data 18

Conclusions  Need to know when it is safe to send data for safety and security reasons  Also beneficial for evaluating performance  Existing signaling protocol standards are clear  Ingress is supposed to wait for Resv before sending data (even if Upstream Label is used)  Egress may consider it safe to send data when Path is received  Pipelining techniques may be used to reduce setup times  Pipelining introduces complications when determining when it is safe to send data  May cause false perception of performance  Can use protocol techniques (ResvConf) or data plane tests to establish when it is safe to send data  Best to apply strict protocol rules  Need to consider whether additional techniques are needed to optimize LSP setup performance  How fast can GMPLS equipments set up an LSP?  How fast do we need to setup an LSP? 19

References  [RFC3209] Auduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP tunnels,” RFC 3209, December  [RFC3471] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” RFC 3471, January  [RFC3473] Berger, L., “Generalized Multi-Protocol Label switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” RFC 3473, January  [DPPM] Sun, W., and Zhang, G., “Label Switching Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks,” draft-ietf-ccamp-lsp-dppm, work in progress.  [Shiomoto09] Shiomoto, K., and Farrel, A., “Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE,” draft-shiomoto-ccamp- switch-programming, work in progress.  [Munoz09] Munoz, R., Martinez, R., and Casellas, R., “Challenges for GMPLS lightpath provisioning in transparent optical networks: wavelength constraints in routing and signaling,” IEEE Communications Magazine, vol. 47, no. 8, p.p , August  [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., “Multiprotocol Label Switching Architecture,” RFC 3031, January  [RFC3945] Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” RFC 3945, October