a service edge based approach for a dynamic and flexible ...€¦ · a service edge based approach...
TRANSCRIPT
NNTF / 20.09.2012 –public– Leymann / Service Edge 1
A Service Edge Based Approach for a Dynamic and Flexible Service Creation NNTF2012, Budapest, 20.09.2012 Nicolai Leymann Senior Architect IP-Transport Networks Deutsche Telekom AG
NNTF / 20.09.2012 –public– Leymann / Service Edge 2
Agenda.
Motivation – What are the challenges with todays networks?
Requirements – What do we expect from an edge based service creation?
Architecture – How does an architecture look like?
Challenges – What are the challenges and corresponding solutions?
Outlook – What’s next?
NNTF / 20.09.2012 –public– Leymann / Service Edge 3
Moving Service Creation towards the Edge. What’s a Edge Based Architecture for?
LER
Acces Node
Network Edge
Core LSR LSR
Access
Architecture Textbox Headline Generic approach, used by many standardization bodies. Single Network Node (“Service Edge”) which provides services to end
customers. Including residential and business customers. Might include Whole-Sales, Mobile Backhauling, …
Directly terminate access nodes Services are not scattered within the network Close to customer locations Does not include peering, connectivity to data centers, … LER functionality, not customer specific
Edge Based Service Creation
NNTF / 20.09.2012 –public– Leymann / Service Edge 4
Moving Service Creation towards the Edge. Motivation.
Existing architecture deploys many service and access specific flow points.
Different nodes for service provisioning (even for a single service, e.g. Triple Play).
Different models for business and residential customers.
Today
Simpler network design by collapsing functionality on a single node.
Single provisioning model for residential and business customers.
Simpler access node design (service agnostic).
More flexibility if new services are added or services need to be changed.
Tomorrow
Growing bandwidth demand results in the need for moving services closer to customer.
NNTF / 20.09.2012 –public– Leymann / Service Edge 5
Moving Service Creation towards the Edge. Existing Network Architecture.
Textbox Headline Two service specific VLANs for Residential Customers Two IP addresses (for two service VLANs) Single/Double Play Customers only with one
service VLAN Routing decision at home gateway necessary (two
virtual uplinks) Service specific configuration in Access Node Customer and Product Specific Flow Points Different models for Business Customers
Characteristics of Existing Architecture
Flow Point
Access Nodes Aggr Aggr
BRAS
IPTV Router
LER
Two service specific VLAN per Residential Customer VLAN#1: HSI, VoIP, IPTV-Service VLAN#2: IPTV Specific, Multicast
L2 (Switched) Infrastructure
Traffic Flow VLAN#1
Traffic Flow VLAN#2
Service configuration for VLAN#1 services
Service configuration for VLAN#2 services
NNTF / 20.09.2012 –public– Leymann / Service Edge 6
Moving Service Creation towards the Edge. Requirements of a Edge Based Service Creation.
Architecture Impact
Single point for service provisioning. One model for residential and business services. Simplified IT and provisioning. Easy (hitless) migration for existing architecture. Simple integration of new products.
Gene
ral
IPv4/IPv6, Unicast and Multicast. Lower impact footprint. 1GE/10GE (towards access nodes). 10GE/100GE (towards backbone). Use of LineID.
Techn
ical
Not only technical but also requirements regarding service
provisioning, accounting, assurance need to be fulfilled.
Moving the service creation towards the edge has impact
on network nodes an processes.
NNTF / 20.09.2012 –public– Leymann / Service Edge 7
Moving Service Creation towards the Edge. Simplifying the Network.
Textbox Headline Full Integration of existing service creation and
aggregation in a single network element at the network edge
Elimination of BRAS, IPTV Service Router and aggregation nodes as dedicated network elements Edge implements and optimizes functionalities of those
network elements Simplified and optimized Access Node configuration Simple Ethernet Based 1:1 model
Edge Based Service Creation Characteristics Textbox Headline Integration of Aggregation & Edge Functionalities
Aggre
gation
Internet
LER
IPTV
Single Service Node
NNTF / 20.09.2012 –public– Leymann / Service Edge 8
Moving Service Creation towards the Edge. Complexity Reduction.
Many features are needed to provide service for residential customers
Moving towards a edge based architecture reduces the overall number of features (taking all nodes, Access, Aggregation, IPTV Service Router into account).
Not all features a necessary at the edge node (e.g. Layer 2 features coming from the second (IPTV) service VLAN).
Remarks Feature Analysis
Duplications Remove
Discuss Stable
Model 1 (all services) Model 2 (residential only)
12%
7%
10%
71%
18%
10%
14% 59%
NNTF / 20.09.2012 –public– Leymann / Service Edge 9
Moving Service Creation towards the Edge. Complexity Reduction – Example Multicast (1 of 2). L2 (“switched”) infrastructure in access and aggregation network …
… but L3 feature for Multicast needed (L3 forwarding, IGMP processing) Up to four nodes with IGMP processing (MSAN, Aggregation Nodes, IPTV Service Router)
IGMP join delay varies/not easy to predict Complex interdependency between multiple network elements regarding functionality, scalability and
performance
AN
Internet Service
IPTV Service
CPE L2 Aggregation Network
NNTF / 20.09.2012 –public– Leymann / Service Edge 10
Moving Service Creation towards the Edge. Complexity Reduction – Example Multicast (2 of 2).
Replication in AN, not controlled (all customers are able to receive Multicast traffic)
Not Controlled (Access Node)
AN
Edge Node
simple and efficient optimized bandwidth usage available and widely supported no control (e.g. no difference between single, double
and triple play) impact on wholesales implementation accounting critical
Replication at AN but controlled by Service Edge (e.g. using ANCP)
Controlled by Edge (e.g. ANCP)
AN
Edge Node
ANCP
optimized bandwidth usage network control limited vendor support additional protocol extensions necessary complex (access and edge node) impact on IAD (“IGMP Forking”) Wholebuy/Wholesale
replication
Replication only at Service Edge (@ customer specific service creation)
Controlled by Service Edge
AN
Edge Node
simple Supports edge node concept network control available and widely supported non optimal bandwidth usage
Simple Solution
NNTF / 20.09.2012 –public– Leymann / Service Edge 11
Moving Service Creation towards the Edge. Service Model. Very simple service model, relies on a control session.
Service is „in session“ if control session is up. Service is „down“ if control session is down.
Service specific configuration is downloaded from a central database to Service Edge based on control session establishment. Service change results only in a change to the database. Tearing down and re-establishing the control session establishes also the new/changes service.
Service specific configuration is removed if control session goes down. Parameters are not only bound to the control session. The session setup might also trigger the configuration of additional
VLANs (e.g. for a L2 business service) See next slides for more details.
Moving Service Creation towards the Edge. Service Model.
GE Interface to AN
VLAN_port-1 VLAN#1
VLAN_port-2 VLAN#1
….
VLAN#2 VLAN#3
Port specific VLAN Tag Corresponds to the customer (HG, CPE, ...) sent
C-Tag VLAN, service-specific)
“Session” (e.g. PPPoE, DHCPv4, DHCPv6, …)
Residential Customer with Internet Access and Triple
Play Service Business Service, Control Session
in VLAN#1, Management in VLAN#2 and Internet Access (Data) in VLAN#3
To the traffic from a port a unique tag is added at the access node. Customer specific tags are carried transparently within the Interface Tag (1:1 model
between AN and Service Node). Number of customers/port per AN is limited by the number of VLAN tags (0-4095).
NNTF / 20.09.2012 –public– Leymann / Service Edge 13
Moving Service Creation towards the Edge. Session- and Access-Oriented Parametrization.
Network Profile
Session
- Session-oriented Parameterization
- Access-oriented Parameterization
Control - Session
access - related bundle of service
Network Profile
access - related bundle of service
Network Services
The “session oriented” model includes services which are fully provided within the control session.
mainly for residential/retail.
The “access oriented” model includes services which establishes additional “network services” in parallel to the corresponding control session
all business services, whole sale services.
network services are using separate vlans.
Remarks
Moving Service Creation towards the Edge. Session- and Access-Oriented Parametrization.
1
Network Service ID: 1
Network Service Type: VLAN
Type ID: #1
… (QoS Profile, Bit Rate, …)
Network Service ID: 2
Network Service Type: VLAN
Type ID: #2
Network Service ID: 3
Network Service Type: VLAN
Type ID: #3
2
Network Service ID: 1
Network Service Type: VLAN
Type ID: #1
… (QoS Profile, Bit Rate, …)
3
…
Network Service Control Session
Network Service Control Session
Network Service Remote Device Management
Network Service Data Channel Internet Access
Network Service Control Session
AN Service Node CPE
Platform wide Database
a) LineID identifies customer (profile) in system wide database
2 3
1
c) Control session setup transmits LineID to Service Node
d) Service Node queries database to retrieve customer profile
e) Customer profile is configured/provisioned
control session
b) Corresponding database entry includes service profile
1 query
conf
NNTF / 20.09.2012 –public– Leymann / Service Edge 15
Moving Service Creation towards the Edge. Complexity Reduction – Multicast in Wholesales (1 of 3). Layer 2 Wholesale Access models are currently under heavy discussion More and more providers are agreeing on L2 based Bitstream Access (e.g. “NGA Forum” in Germany) In the past 1:1 models between Wholesale ISP and Wholesale customer caused a lot of complexity
Agreement on VLAN IDs between WS IPS and WS Customer Configuration changes in Access Nodes Careful Address Planning (VLANs)
A Service Edge in combination with a simplified Access Node can help to overcome these problems. It enables the use of an automated 1:1 model between WS ISP and WS Customer.
NNTF / 20.09.2012 –public– Leymann / Service Edge 16
Moving Service Creation towards the Edge. Complexity Reduction – Multicast in Wholesales (2 of 3).
1:1 Multicast Wholesales Model:
c#2
VLAN 1001 for traffic from customer #1
VLAN 1002 for traffic from customer #2
Access Node Service Edge
c#1u
Service VLANs
Service VLANs
A10
-NS
P
VLAN tag separates customers
N:1 Multicast Wholesales Model:
c#2
Access Node Service Edge
c#1u
Service VLANs
Service VLANs
A10
-NS
PVLAN 1001 for service #1 (all customers)
VLAN 1002 for service #2 (all customers)
VLAN 1003 for service #3 (all customers)
All customers in one instance, additional traffic separation necessary
NNTF / 20.09.2012 –public– Leymann / Service Edge 17
Moving Service Creation towards the Edge. Complexity Reduction – Multicast in Wholesales (3 of 3).
1:1 Multicast at AN and Service Edge Easy to implement and transparent for Multicast traffic (based
on 1:1 Service Model) Multicast handling only at Wholesale Customer necessary
Simple packet forwarding at WS Service Provider no IGMP processing no Multicast specific forwarding
N:1 Multicast at AN and Service Edge Single domain for many customers, no separation of traffic
(additional mechanisms needed, e.g. split horizon) Full Multicast functionality at Wholesale ISP necessary
Shared resource (e.g. IGMP performance, join/leave delays, careful planning necessary)
A Service Edge significantly reduces the complexity of the 1:1 Wholesale Model.
NNTF / 20.09.2012 –public– Leymann / Service Edge 18
Moving Service Creation towards the Edge. Summary.
The Edge Based Architecture reduces the overall complexity of the network. Simplified Access Node (standard configuration, no service dependencies). Unified service model provides more flexibility (time to marked with new products).
Service Node implements functionality from Aggregation, BRAS and IPTV Service Router. A Service Node enables the use of 1:1 models for wholesales.
NNTF / 20.09.2012 –public– Leymann / Service Edge 19
Thank you very much.
21 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
INTELLIGENT CUSTOMER EXPANDABLE AAA FRAMEWORK (ICE AAA)
Dean Bogdanovic Solution Architect, Director, Management and Virtualization Platform [email protected]
22 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
WHAT IS ICE AAA FRAMEWORK?
Provides a way to handle AVPs/VSAs not supported by JUNOS today (and maybe ever).
Provides a standards based interface that:
Provides an Sd/Diameter or RADIUS interface on Junos platform functioning in a “push” model from a AAA system
Provides opt-in determination allowing for selective enablement of the service to only interested subscribers
Provides a policy instantiation function to steer subscriber traffic to ANY services application in the Junos services plane now and for whatever is developed in the future
Provides a route injection function to steer traffic back to the Junos platform
23 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
OPPORTUNITIES FOR ICE AAA FRAMEWORK
Enable network control platform (RADIUS or DIAMETER) to:
Route download
NAT Logging
Interface description
Dynamic configuration
Service Delivery Gateway
24 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
NETWORK TOPOLOGY
25 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
NETWORK TOPOLOGY (SERVICE DELIVERY GATEWAY)
26 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
ICE DICTIONARY FILE
<?xml version="1.0" ?>
<iceaaa-dictionary>
<version>1.0</version>
<radius> or <diameter>
<std-attribute-list>
<std-attribute>
<attribute-name> </attribute-name>
<attribute-type> </attribute-type >
<attribute-data-type></attribute-data-type>
</std-attribute>
<std-attribute>
<attribute-name> </attribute-name>
<attribute-type> </attribute-type >
<attribute-data-type></attribute-data-type>
</std-attribute>
</std-attribute-list>
27 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
ICE DICTIONARY FILE CONT’D
<vsa-list>
<vsa>
<vendor-id></vendor-id>
<attribute-name> </attribute-name>
<attribute-type> </attribute-type >
<attribute-data-type></attribute-data-type>
<action-list>
<action-set>
<provision-action>
<action-type>op-script</action-type>
<action>
<version>1</version>
<name></name>
<param1></param1>
<param2></param2>
</action>
</provision-action>
28 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
OVERVIEW (RADIUS)
JUNOS
RE SDK App
CLI
libjunos-sync
DDL/ODL Interface Description
RADIUS Analyzer
AVP Processor
Session DB
AAA Snooper
Op script service
Raw Sockets
AVP Manager
Dictionary
ICEAAA Framework
KCOM libjunos-sdk
Stats collector
SDK app service
29 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
MAIN MODULES
RADIUS Analyzer
AVP Manager
Stats collector
Session DB
Dictionary
Opscript service
SDK App service
30 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
OVERVIEW (DIAMETER)
JUNOS
RE SDK App
PCRF
KCOM
libdfwd
libssd
Junos CLI
SSD
RPD
DFWD
Routing Table
libjunos-sync
DDL/ODL Interface Description
Diameter Analyzer
AVP Processor
Session DB
Sd interface
Juniper Diameter Stack
Wrapper
Filter Manager
Route Manager
SRM Service DB
FreeBSD Sockets
AVP Manager
Dictionary
Service Resource Manager
ICEAAA Framework
31 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
MAIN MODULES
• Diameter Analyzer
• Service resource management
• Route management module
• Filter management module
32 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
DICTIONARY
<?xml version="1.0" ?>
<iceaaa-dictionary>
<diameter>
<std-attribute-list>
<std-attribute>
<attribute-name>ADC-Rule-Name</attribute-name>
<attribute-code>1096</attribute-code>
<attribute-type>OctetString</attribute-type>
</std-attribute>
<std-attribute>
<attribute-name>ADC-Rule-Base-Name</attribute-name>
<attribute-code>1095</attribute-code>
<attribute-type>UTF8String</attribute-type>
</std-attribute>
</std-attribute-list>
33 Copyright © 2012 Juniper Networks, Inc. www.juniper.net
DICTIONARY CONT’D <service-list> <service> <Vendor-Id>10415</Vendor-Id> <Auth-Application-Id>16777303</Auth-Application-Id> <ServiceName>RelevantAds</ServiceName> <action-list> <action-set> <provision-action> <action> <action-type name="API">2</action-type> <version>1</version> <name>SRM</name> <param>Session-Id</param> <param>Origin-Host</param> <param>Origin-Realm</param> <param>Destination-Realm</param> <param>Destination-Host</param> <param>Framed-IP-Address</param> <param>AN-GW-Address</param> </action> </provision-action> <update-action> </update-action> <remove-action> </remove-action> </action-set> </action-list>