Thank you to everyone who joined SDxCentral for their first 2015 SDxCentral SDN Controller Report webinar featuring Ericsson. Our presenters focused on service provider SDN and software-defined networking agility. This fascinating presentation on service provider SDN started with SDxCentral Roy Chua’s address of the state of today’s SDN Controller market. Following that, top SDN use cases were reviewed and the dominant market approaches (mostly OpenDaylight-based) were discussed. Webinar attendees were able to better understand Ericsson’s more holistic approach to SDN, and service provider SDN specifically. Finally, Bala Thekkedath touched on the role SDN plays in operationalizing network functions virtualization (NFV).
Whose point of view is this from? Enterprise or service provider?
Ericsson: This is covered from a service provider standpoint
You use the term “SDN Service Chaining,” but in the ETSI NFV Reference Architecture, they use the word “orchestration.” Is SDN Service Chaining and NFV orchestration the same thing? Meaning are they both dynamic and programmatic?
Ericsson: They are not the same thing although they have a relation. NFV orchestration as defined by ETSI MANO is about deployment, configuration and lifecycle management of the VNFs which is part of this process. There is also the definition of the network traffic flow between VNFs or VNF components. This is where SDN Service chaining comes into play to define the traffic steering and forwarding behaviors between the VNFs. ETSI NFV defines the notion of VNF Forwarding Graphs, which is a graph of logical links connecting network function nodes for the purpose of describing traffic flow between these network functions. SDN Service Chaining as part of the NFV Infrastructure is one way of realizing the VNF Forwarding Graph.
Ericsson: IP stack here refers to the BGP VPN (MP-BGP) control plane running in the centralized SDN Controller (cloud SDN Controller) programming distributed forwarders (virtual switches in compute nodes supporting MPLS forwarding and physical switches, e.g. top-of-rack (TOR) switch supporting VxLAN) to achieve virtual networking in the data center, using proven technologies such as BGP VPNs.
BGP protocol scales well in data centers and is a proven protocol that has been supporting the Internet backbone for the past decades; hence it is a proven control plane protocol. In the case of the forwarding plane, the Ericsson cloud SDN architecture supports a distributed forwarding architecture where BGP VPNs are implemented all the way to the vSwitch (Ericsson Cloud SDN Switch based on Open vSwitch) residing in the compute node hypervisor. So using centralized BGP control plane in the SDN Controller coupled with distributed forwarding allows scalable and high performance data center networking to support NFV deployments.
Are transport SDN, cloud SDN, and services SDN packages different on module day 1 or would they be activated as customer pays for those features?
Ericsson: All these packages execute on the same OpenDaylight Controller and can be activated depending on how they are placed with in the network domain, so yes, they can be activated based on what the customer pays for.
How successful has Ericsson services been in SDN transport network?
Ericsson: We are in early lab efforts with various customers at this point.
Is your policy implementation embedded in ODL Controller?
Ericsson: The ODL Controller supports a policy application that translates subscriber policies (received from PCRF or AAA) into forwarding rules. The ODL Controller also implements other policy frameworks such as Group Based Policy (GBP).
What’s the physical layer below your current SDN architecture? How do you manage this functionality with a mix of existing legacy non-SDN architecture?
Ericsson: Ericsson relies on the Model Driven Service Abstraction Layer (ODL MD-SAL layer) to model network services using YANG modeling and YANG tools. MD-SAL then uses various southbound protocols to render the services into a mix of physical nodes configuration and programming rules. Depending on the legacy system capability, ODL would use the necessary southbound protocol to program and configure the legacy system (Netconf, SNMP etc). This way of modeling service using an abstraction layer (MD-SAL) makes it much easier to develop network services independent from the underlay based legacy physical systems. This way more systems can be supported just by adding the southbound protocol support for the legacy system.
Is the service chaining automated or does it need manual intervention?
Ericsson: The service chaining has two aspects:
- The first aspects is the configuration of the actual service chain (chain definition, type of service function in the chain etc) and this service chaining aspect can be configured through an orchestration system as defined in MANO from ETSI architecture – this forms a pre-defined service chain.
- The second aspect of service chaining is the mapping of traffic or flows into the previously pre-defined service chains and this can be done dynamically using protocol signaling between a PCRF or AAA and the policy application running on the ODL Controller.
This is why we refer to dynamic service chaining since this second part of the service chaining doesn’t require any configuration or manual intervention.
The overlay model does not bring financial advantages, as complexities are not reduced. Why should an operator then go towards SDN if there is the risk that it is even more expensive?
Ericsson: Overlay models help simplify the solution and complexities are reduced from an orchestration and agility standpoint. It makes networking configuration and automation in the data center easier since it’s independent from the underlying physical data center infrastructure solution chosen by the operator. It’s agnostic from the fabric hardware vendor and also agnostic to the protocols/capabilities supported by the hardware fabric since overlay tunnels are built on top of this fabric, which allows deploying SDN over a non-SDN fabric or across different fabric vendors that don’t have all the same capabilities. It allows multiple benefits:
- The application level (VNFs, IT, enterprise apps) doesn’t need to worry about underlying physical hardware in the data center fabric, they only request virtual networks to be created by the SDN layer without worrying about the data center fabric networking capabilities. This allows applications to focus more on their core business logic and only use ‘high level’ programmable interfaces towards an SDN Controller to request networking connectivity along with required SLAs.
- Overlay SDN allows the data center operators to upgrade and manage the underlay fabric (capacity upgrade or fabric redesign, new fabric technology or vendor introduction) without impacting the applications using those virtual networks managed by the overlay SDN layer.
There is also a need for the SDN layer (overlay SDN Controller) to also interact with the underlay layer (data center fabric) for better operation: understand the fabric topology and correlate the physical paths with the overlay tunnels running on top, to offer better SLAs and monitoring of the overlay networks.
What does NFV orchestration have to do with onboarding of network functions and their life cycle management? What were your pain points in selling/optimizing Ericsson’s SDN transport services?
Ericsson: NFV orchestration is achieved through OpenStack VIM layer – Nova interface. The Ericsson Cloud Manager (ECM) is the orchestrator that manages life cycle of VMs. Ericsson’s SDN transport system is in its early customer lab entry efforts and we have not seen that many issues as of yet.
The benefits of the solutions are quite clear. Will you also discuss some of the initial challenges for the operators to integrate these into their present mode of operation?
Ericsson: Some of the larger issues have been in the following areas:
- Ability to migrate to this new way of thinking in a holistic manner when it comes to SDN/NFV in general
- Ability to configure legacy equipment and associated interworking through plug ins and associated modeling
- Ability to get the necessary competence in place to bring about the necessary change
Do you have the controller/orchestrator software available over Amazon Web Services (AWS) or any other public cloud?
Ericsson: Our focus today remains towards service provider needs and requirements not with public cloud providers as yet.
Rapid service delivery has been promised in the past by using IMS Platform and building all new service application services on IMS. How does Ericsson IMS platform take advantage of the SDN Controller?
Ericsson: Ericsson Cloud SDN Controller will have the ability to provide all IMS related networking needs using the controller.
I would like to see how this could be implemented in a data center for basic Layer 2/3 and virtualization.
Ericsson: Ericsson Cloud SDN solution uses overlay tunneling such as VxLAN in a similar way as VMware NSX however Ericsson solution is fully based on an open source controller, but also has a different approach and architecture for interconnecting data center PODs or interconnecting different data center networks across the wide area network (WAN).
Ericsson Cloud SDN uses a distributed architecture with BGP MPLS VPN forwarding up to the compute nodes whereas others use a centralized architecture with software or physical gateways implementing BGP VPN that can be a bottleneck for many of the NFV deployments. An open source solution based on OpenDaylight helps operators bring together an open ecosystem with well-defined community driven APIs and help other third party partners also develop their own SDN applications using the same OpenDaylight platform.
For the three integrated solutions, what are the scales these solutions have been tested or deployed?
Ericsson: The three solutions will support typical tier 1 performance requirements.