A Service Edge Based Approach for a Dynamic and Flexible ...€¦ · A Service Edge Based Approach for a Dynamic and Flexible Service Creation NNTF2012, Budapest, 20.09.2012 Nicolai

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


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?


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


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.


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


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.


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


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%


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


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


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).


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, …)



Type ID: #2



Type ID: #3

2



Type ID: #1

… (QoS Profile, Bit Rate, …)

3

…

Network Service Control Session


Network Service Remote Device Management

Network Service Data Channel Internet Access


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


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.


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


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.


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.


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]

mailto:[email protected]


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


OPPORTUNITIES FOR ICE AAA FRAMEWORK

Enable network control platform (RADIUS or DIAMETER) to:

Route download

NAT Logging

Interface description

Dynamic configuration

Service Delivery Gateway


NETWORK TOPOLOGY


NETWORK TOPOLOGY (SERVICE DELIVERY GATEWAY)


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>




</std-attribute>

</std-attribute-list>


ICE DICTIONARY FILE CONT’D

<vsa-list>

<vsa>

<vendor-id></vendor-id>




<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>


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


MAIN MODULES

RADIUS Analyzer

AVP Manager

Stats collector

Session DB

Dictionary

Opscript service

SDK App service


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


MAIN MODULES

• Diameter Analyzer

• Service resource management

• Route management module

• Filter management module


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>


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>

Documents

A Service Edge Based Approach for a Dynamic and Flexible ...€¦ · A Service Edge Based Approach for a Dynamic and Flexible Service Creation NNTF2012, Budapest, 20.09.2012 Nicolai