www.mpls2009.com when is it safe to send data in a network controlled by a gmpls control-plane?...
TRANSCRIPT
www.mpls2009.com
When is it safe to send data in a network controlled by a GMPLS
control-plane?
Kohei Shiomoto Adrian Farrel NTT Old Dog
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
GMPLSControl-plane for multiple switching technologies
data-planeSignaling protocol: RSVP-TEUnidirectional and Bidirectional LSPs
Problem to be solvedWhen is it safe to send data?
Existing standard signaling protocol specificationFundamental message processing rulesNote for bidirectional LSP
Implementation considerationPerformance interpretationPerformance 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
t0 t2
t0 t2
t0 t2
t0 t2
N
1
:
N
1
:
N
1
:
N
1
:
Fiber#1Fiber#N
Fiber#1Fiber#N
Fiber#1Fiber#N
Fiber#1Fiber#N
FiberSwitch(FSC)
LabelSwitch(PSC)
IP16
IP18IP32
IP61
TDMSwitch(TDM)
LambdaSwitch(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 2
1
2LSR1
Port 2 Port 1
Controler 1 Controler 2 Controler 3
Controler 4
Data plane
D-planeswitch
LSR2 LSR3
Signaling protocol : RSVP-TE
RSVP-TE is the signaling protocol for GMPLS.Path msg. from ingress to egressResv msg. from egress to ingress
6
Path
Path
Path
Resv
Resv
Resv
LSR A LSR B LSR C LSR D
Bi-directional LSPs
Both forward and backward LSPs are created in data plane by a single signaling exchange.
7
Path
Path
Path
Resv
Resv
Resv
LSR A LSR B LSR C LSR D
What does it mean to be “safe to send data”?
Data that is sent should be delivered to the LSP egressReliable data delivery
Data that is sent must not be delivered to the wrong egressSecurity 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 4.1.1.1]
Thus the ingress LSR can safely start to send data when it receives the Resv msg. (and programs its own XC).
10
Path
Path
Path
Program XCResv
Program XC
Program XC
Program XC
Resv
Resv
LSR A LSR B LSR C LSR 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
Path /w UL
Path /w UL
LSR A LSR B LSR C LSR D
Resv
Program XC
Program XC
Program XC
Program XC
Resv
Resv
OK
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
Path /w UL
Path /w UL
Program XCResv
Program XC
Program XC
Program XC
Resv
Resv
LSR A LSR B LSR C LSR D
ResvConfOK
OK
LSR
D-planeswitch
Implementation consideration
13
Fiber#1
Fiber#N
Fiber#1
Fiber#N
Fiber#1
Fiber#N
Fiber#1
Fiber#N
FiberSwitch(FSC)
LabelSwitch(PSC)
IP16
IP18IP32
IP61
t0 t2
t0 t2
t0 t2
t0 t2
TDMSwitch(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.
LambdaSwitch(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. 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
Path
Path
Program XCResv
Program XC
Program XC
Resv
Resv
LSR A LSR B LSR C LSR D
Program XC
Slow!TD
TCProgram XC
Program XC
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
Path/w SL
Program XC
Resv
Resv
LSR A LSR B LSR C LSR D
Rejected SL&
Re-program XC
Resv
Path/w SL
Program XC
Program XC
Program XC
Path/w SL
Path/w SL
Resv
Resv
LSR A LSR B LSR C LSR 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
Path
Path
Program XC
Resv
Program XC
Program XC
Resv
Resv
LSR A LSR B LSR C LSR D
Program XC
Program XC
Program XC
Data test (fwd)
OK (fwd)Data test (bwd)
Data test (fwd)
Data test (fwd)
Data test (fwd)
Data test (bwd)
Data test (bwd)
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 5.1.1 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
Path
PathProgram XC
Resv
Program XC
Program XC
Resv
Resv
LSR A LSR B LSR C LSR D
Program XC
Program XC
Program XC
OK (bwd)
Data test (fwd)
OK (fwd)Data test (bwd)
Data test (fwd)
Data test (fwd)
Data test (fwd)
Data test (bwd)
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 enoughThe important feature is when it is possible to
start sending dataNeed 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 dataMay cause false perception of performanceCan use protocol techniques (ResvConf) or data plane tests
to establish when it is safe to send dataBest 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 2001.
[RFC3471] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” RFC 3471, January 2003.
[RFC3473] Berger, L., “Generalized Multi-Protocol Label switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” RFC 3473, January 2003.
[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. 26-34, August 2009.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., “Multiprotocol Label Switching Architecture,” RFC 3031, January 2001.
[RFC3945] Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” RFC 3945, October 2004.
20