Implementation of an OBS access node supporting multiple ... · PDF fileFTTH OLT ROADM Long...
Transcript of Implementation of an OBS access node supporting multiple ... · PDF fileFTTH OLT ROADM Long...
© 2012 MAINS Consortium
Víctor López1, 3, Georgios Zervas2, Yixuan Qin2, Sergio Lopez-Buedo1, Dimitra Simeonidou2, Javier Aracil1 and Juan Fernandez-
Palacios3 1Universidad Autónoma de Madrid
2University of Essex 3Telefónica I+D
July, 2012
Implementation of an OBS access node supporting multiple services
© 2012 MAINS Consortium 1
Index
n Motivation
n MAINS Reference Architecture
n Prototype Implementation Architecture — Use case for the OBS access node
— Implementation
n Prototype Behavioural Validation
n Conclusions
© 2012 MAINS Consortium 2
Motivation
n Operators are interested on Network Centric Services (NCS)
n What is a NCS?
— Combined user of both network and IT resources.
— Examples:
– PC virtualization, VoD, 3D Internet gaming, SaaS and SAN
Operator’s Network
End user
Mul4Service Server cloud
© 2012 MAINS Consortium 4
Metro Architecture n Centralized cloud approach: Few servers located in core nodes
n Distributed cloud approach: Mul2ple mul2purpose servers located in metro and core nodes
ONU
FTTB
FTTH
OLT
ROADMROADM ROADMROADM
Long Reach WDM-PON
IP/MPLS Routers interconnected by
OBS/OPST networks
ROADM OBS ROADM OBS ROADM OBS
ONU
FTTB
FTTH
OLT
ROADMROADM ROADMROADM
Long Reach WDM-PON
IP/MPLS Routers interconnected by
OBS/OPST networks
ROADM OBS ROADM OBS ROADM OBS
High bandwidth consump4on
High computa4on
Just required bandwidth Low cost servers
Low latency: minimum delay
© 2012 MAINS Consortium 5
Motivation
n Why NCS? — Operator’s perspective:
– Network scalability
– New business opportunity – CAPEX and OPEX optimization
— End user’s perspective: – Availability
– Mobility – IT maintenance outsourcing
– QoE: low latency and high bandwidth
n Increment of network traffic will impact on metro network — New metro architecture is required to support such services.
© 2012 MAINS Consortium 6
Motivation
n Metro Architectures enabliNg Subwavelengths (MAINS) project proposes a new metro architecture based on two pillars:
— Subwavelength optical switching technologies in the Data Plane.
— Enhanced GMPLS architecture in the Control Plane.
n The objectives of such architecture are:
— Reduce cost and energy consumption.
— Improve reliability and latency.
J. Fernandez-Palacios, et al., Metro Architectures enabliNg Subwavelengths: Rationale and Technical challenges, in Future Network & Mobile Summit, Jun, 2010.
© 2012 MAINS Consortium 7
Index
n Motivation
n MAINS Reference Architecture
n Prototype Implementation Architecture — Use case for the OBS access node
— Implementation
n Prototype Behavioural Validation
n Conclusions
© 2012 MAINS Consortium 8
MAINS Reference Architecture
Applica2on Server(s)
Applica2on Client/Server
MAINS Network Service Interface (MNSI)
Middleware Middleware
XML Interface XML Interface XML Interface
TSON Mesh
OPST Ring
Access (LAN + last-‐mile)
OPST Ring
MNSI
MW interface
Data transport
Data transport
Subwavelength-‐enabled GMPLS CP
Metro/regional segment
Access (LAN + last-‐mile)
MNSI Gateway
MNSI Gateway
CPE CPE
© 2012 MAINS Consortium 9
MW i/f 2. NSI Request connection from
IP1 to IP2
5. Data transference 6. Application 1. Middleware information exchange
VM transference
GMPLS CP UNI-N UNI-N
XML i/f
MNSI GW
Transport Network (OPST/OBST)
MNSIGW
Extended UNI Extended UNI
Application Server 1
Edge Node
Edge Node
NSI
Middleware
Data plane i/f
Application Server 2
Middleware
Data plane i/f
NSI
User Network
User Network
IP1 IP2 Connect
VLAN OK Reply
Job DB Query New task Send data from IP1 to IP2
MAC1 MAC2 Info MAC2 MAC1 Info
Content Streaming
4. Control plane configuration
User request a Virtual PC service
New task
© 2012 MAINS Consortium 10
Index
n Motivation
n MAINS Reference Architecture
n Prototype Implementation Architecture — Use case for the OBS access node
— Implementation
n Prototype Behavioural Validation
n Conclusions
© 2012 MAINS Consortium 11
Prototype Implementation Architecture
n Metro network supports multiple services at the same time.
n A prototype is developed with the following requirements: — Data plane burst transmission
— VLAN support for multiple services
© 2012 MAINS Consortium 12
4. Ethernet Packets
extracted
Use case for the OBS access node
TX/RX Burst
Application Server 2
Middleware
Data plane i/f
Application Server 1
Middleware
Data plane i/f
1. Service configuration
(VLAN, Burst_Size,
Burst_Timer)
Payload VLAN1 Payload VLAN1
Payload VLAN2
VLAN1 – Burst_Size ++ VLAN1 – Timer Start
Payload VLAN1
VLAN2 – Burst_Size ++ VLAN2 – Timer Start
2. Data transmission
3. Any threshold is exceeded
(Timer VLAN2)
Burst VLAN_2 Payload VLAN2
© 2012 MAINS Consortium 13
Implementation: Board details
n Xilinx® Virtex™-5 PCI Express Development Kit (Avnet) — Xilinx Virtex-5 XC5VSX95T-FF1136 FPGA
Two Small-Form Pluggable (SFP) cages
Puerto Gbe
Puerto Gbe
© 2012 MAINS Consortium 14
Implementation: Modules
ETH CLK DOMAIN ROCKETIO CLK DOMAIN
ROCKETIO CLK DOMAIN SCHEDULER CLK DOMAIN
SCHEDULER TX RocketIO
BURST2ETH RX RocketIO
GbE RX DATA
FIFO
Scheduler2RocketIO
VLAN + SIZE FIFO
ETH CLK DOMAIN
ETH2 SCHEDU
LER
GbE TX
© 2012 MAINS Consortium 15
Implementation: TX modules
n Functions: — Eth2Scheduler: get VLAN_id and packet size while storing the
incoming packet
— Scheduler: burst generation and management
— Scheduler2RocketIO: burst adaptation and transmission
ROCKETIO CLK DOMAIN SCHEDULER CLK DOMAIN
SCHEDULER TX RocketIO GbE RX DATA
FIFO
Scheduler2RocketIO
VLAN + SIZE FIFO
ETH CLK DOMAIN
ETH2 SCHEDU
LER
© 2012 MAINS Consortium 16
Implementation: SERDES interfaces
n SERDES interfaces are Serializer/Deserializer interfaces. — Input – output parallel interfaces has 16 bits.
— Physical transmission is done with a differential signal.
High-Speed Serial I/O. Made Simple. A Designers' Guide, with FPGA Applications. R by Abhijit Athavale and Carl Christensen. Available online
© 2012 MAINS Consortium 17
Implementation: SERDES interfaces
§ There is a 8B/10B module to provide redundancy.
§ Channel management uses K-Characters
— TXCHARISK signal is asserted if TXDATA is a K-Character.
TXDATA [15:0] TXCHARISK [1:0]
© 2012 MAINS Consortium 18
How to create a burst?
§ There are two solutions to create a burst: — Send burst structure information in the burst control packet.
— Insert K-characters in the burst while transmitting.
§ There are two special characters for our burst:
— End of burst character
— Start of packet character
Packet ETH3 Packet ETH2 Packet ETH1 Flag 2 Flag 1 Flag 1 Flag 1 EOB SOP SOP SOP
© 2012 MAINS Consortium 19
Implementation: RX Modules
n Functions: — Burst2Eth:
– Extract packets from the burst
– Transmittion over GbE interface
ETH CLK DOMAIN ROCKETIO CLK DOMAIN
BURST2ETH RX RocketIO GbE TX
© 2012 MAINS Consortium 20
Index
n Motivation
n MAINS Reference Architecture
n Prototype Implementation Architecture — Use case for the OBS access node
— Implementation
n Prototype Behavioural Validation
n Conclusions
© 2012 MAINS Consortium 21
Figure 5: Packets per second when transmitting bursts with size threshold of 50 packets
4.2 Support to multiple services
In the second experiment, traffic with two VLAN tags is transmitted. To have a Wireshark capture, the Access Node 1 (Figure 4) is connected in loopback so the burst is created and received in Access Node 1. For VLAN 10 and VLAN 7 the timer threshold is set to 0.5s and 0.25s accordingly. Figure 6 shows the capture and the difference from the first packet arrival to the first packet reception for VLAN 10 is around 0.5s, while for VLAN 7 the difference is 0.25s. This validates that the access node is able to provide different delay based on the VLAN tag.
Figure 6: QoS variation based on VLAN tag
5. CONCLUSIONS This article describes in detail the architecture for a multi-service OBS access node based on a Virtex 5 FPGA. The modules of the access node are described and their functionality to support multiple services on an access node. The paper shows a behavioural validation of the prototype under traffic from two different services.
ACKNOWLEDGEMENTS This work has been supported by the European Commission Seventh Framework Programme through IST STREP project MAINS (INFSO-ICT-247706).
REFERENCES [1] Cs. Kiss Kalló, et al, “Cost-Effective Sub-wavelength Solution for Data Centre Location
in Scaled Next-Generation Networks”, in Optical Networking Design and Modeling (ONDM), Apr, 2012.
[2] P. Pavon-Marino and F. Neri, “On the Myths of Optical Burst Switching”, in IEEE Transactions on Communications, 59(9), 2574–2584, September 2011.
[3] G. Zervas, et al, “Time Shared Optical Network (TSON): A Novel Metro Architecture for Flexible Multi-Granular Services”, Optics Express Vol. 19, Iss. 26, pp. B509-B514, September 2011.
[4] J. Fernandez-Palacios, et. al, “Metro Architectures enabliNg Subwavelengths: Rationale and Technical challenges”, in Future Network & Mobile Summit, June 2010.
[5] G. Zervas et al., “A Fully Functional Application-aware Optical Burst Switched Network Test-bed”, in Proc. of the OFC/NFOEC, March 2007.
QoS support for multiple VLANs
26
VLAN 10 Timer 0.5s
VLAN 7 Timer 0.25s
Burst size threshold validation
n For this experiment, the application server 1 sends traffic to the application server 2 with a fixed packet size of 128 bytes.
n The burst size threshold is set to 6400 bytes (50 packets). Based on the PCAP file captured at Server 2, the burst is correctly transmitted.
TX/RX Burst
Application Server 2
Middleware
Application Server 1
Middleware
Data plane i/f Data plane i/f
Access Node 1 Access Node 2
Whireshark
© 2012 MAINS Consortium 22
Support to multiple services
VLAN 10 Timer 0.5s
VLAN 7 Timer 0.25s
TX/RX Burst
Application Server 1
Middleware
Data plane i/f
Access Node 1 Access Node 2
Loop-‐back
Whireshark
© 2012 MAINS Consortium 23
Index
n Motivation
n MAINS Reference Architecture
n Prototype Implementation Architecture — Use case for the OBS access node
— Implementation
n Prototype Behavioural Validation
n Conclusions
© 2012 MAINS Consortium 24
Conclusions
n MAINS project is exploring sub-wavelength technologies as an efficient solution for metro networks.
n The architecture for a multi-service OBS access node based on a Virtex 5 FPGA is detailed explained.
n The modules of the access node are described and their functionality to support multiple services on an access node.
n A behavioural validation of the prototype under traffic from two different services is presented.