===!"§ Deutsche Telekom Innovation Center Deutsche Telekom AG Innovation Center Scenarios for...

===!"§Deutsche Telekom Innovation Center

Deutsche Telekom AGInnovation Center

Scenarios for L1VPNs September 26, 2005Discussion paper for NOBEL Paris Meeting September 2005Georg Lehr, T-Systems SSC ENPS PCT 52gl


Outline

L1VPN – A simple approach, benefits for customers and providers

Scenarios for Takeda framework Assessment of L1 VPN Discussion of broadcaster’s scenario


Simple view

Definition of Virtual Private network: — Network can be operated as if it was fully owned by the customer.

• e.g. private address plan• full management visibility and management capabilities on own resources• no impact of “outer world” (security/privacy; closed user group …)

— This ownership is only virtual, as it is partly shared with other customers Sharing can be on:

— data plane level : (transmission resources such as subnetworks, nodes, or links are shared)

— level of control : • control plane hard and software; • but: information exchanged by routing protocols is dedicated (membership,

customer routing info and provider routing info is only exchanged between the PE and CE members of the VPN).

— level of management and operation: • management infrastructure is shared, • operational labour and expertise is shared.• but: management information is dedicated (customer’s management view and

capabilities are restricted to VPN resources)

… on L1VPNs


Simple view

Sharing has two aspects:— economies of scale regarding resources and operation.— economies of expertise

These aspects enable— Attractive costs for production— Outsourcing and other value added services

Additional effort for implementation— limitation of distribution of information within VPN

• in CP via routing protocols• in MP via access rights on resources• both: measures to guarantee security

— limitation of access to resources • in CP policing functions (CAC-functions)• in MP see above• both: measures to guarantee security

Competition, if services are comparable and provided via standardized interfaces— data level is standardized— CP is going to be standardized— MP interfaces: chance to provide proprietary solution with high customer benefit

(e.g. in systems solution business).

… on L1VPNs


Customer benefits

Customer can outsource operation of an Layer 1 Network. This takes the burden from the customer: —to perform the network management tasks —to provide a 7/24 service / helpdesk—to train and employ people with a very specialized operational

experience (with skills often far away from the core business).—to operate a complicated network management infrastructure

Sharing of resources: —customer can afford small network by sharing the full cost of

ownership with other customers. The smaller the network is, the better the economy of scale (for equipment and labour).

… of L1VPNs


Customer benefits (ctd.)

Customer does not have to care about technical details, but can rather rely on parameters guaranteed in SLAs; the provider has to take care how availability goals can be met - also for different routes:—availability —latency —SNR for optical networks—reachability for dynamic services

Customer can integrate networks from different providers with an optimized cost / quality relationship.—different layers—different regions

• “in parallel” (to implement diversity)• in sequence (to build a global network, if no global provider is

available or is too expensive)

… of L1VPNs


Provider benefits

Provider can sell a value added service to the customer, not only connectivity but rather:—supervised connectivity —with guaranteed availability—guaranteed reachability (in terms of busy hour call attempts)—guaranteed latency—Management capabilities such as

• Detailed management access from simple web applications (visibility, fault, performance …)

• Advanced billing functions (e.g. interfaces to SAP …)• Other integration functions (e.g. integration with customer’s order

management, SAP …)• Helpdesk and 7/24 h support

Provider can make better use of spare resources Provider can share the effort for expensive lower layer network

management integration; customer needs only a simple browser.

… of L1VPNs


ITU-T Takeda draft

The ITU-T provided in the Y series some generic views on L1VPNs.

This work has been used as starting point for discussion in IETF.

draft-takeda-l1vpn-framework-04.txt: Tomonori Takeda (Editor): “Framework and Requirements for Layer 1 Virtual Private Networks”; June 2005


Service requirements and service models

Info exchange at CE-PE interface

Data plane shared

Data plane dedicated

Signaling Overlay Overlay Signaling + Membership information

Overlay Extension

Overlay Extension

Signaling + Membership information + Customer network routing information

Virtual Node

Virtual Node

Signaling + Membership information + Customer network routing information + Provider network routing information

Not applicable

Virtual Link

Per-VPN Peer

Possible combinations of info exchange and sharing

draft-takeda-l1vpn-framework-04.txt


Service requirements and service models

The table provides a mapping between service models —overlay —overlay extension, —virtual node, —virtual link, —per VPN peer

to functionality provided by the network —signaling plus—different levels of information transfer

The table distinguishes further between shared and dedicated dataplanes.

Significance of the table


Taxonomy of L1VPN Service Models

Management based service

model

Management based service

model

Control based service modelControl based service model

Signaling based service model

(Overlay service model)*

Signaling based service model

(Overlay service model)*

Signaling and routing service

model

Signaling and routing service

model

Virtual link service model

Virtual link service model

Per VPN peer

service model

Per VPN peer

service model

Type of the customer interface

Type of information exchanged

Type of routing information exchanged

NNI (Peer) type of interfaceUNI (Overlay) type of interface

Draft-takeda-l1vpn-framework-03.txt

Virtual node

service model

Virtual node

service model

OverlayOverlay Overlay (extension

)

Overlay (extension

)

Type of membership information exchanged

Service models are classified by semanticsof information exchanged over the customer interface

* [GVPN] calls this service GVPW (generalized virtual private wire service)


Information exchange at the PE-CE InterfaceCan be used to classify the scenarios

PECE

linkCPI PPI

CEPE

linkPPICPI

GMPLS enabled

BB

•Signaling •Membership information :

•{(CPIn ,PPIn,); ….}; (CPI are private, PPI public addresses)•local (same PE) and remote (other PEs)•distribution restricted to the specific VPN

•Customer network routing information•Provider network routing information

Provider Network

CustomerNetwork

CustomerNetwork


Shared data plane vs. dedicated data plane

Sharing the data plane enables the network operator to better utilize the resources. He can share this advantage with the customer.

Sharing of the resources has impact on:— resource availability— security

Sharing of resources implies, that the customer has no influence on the routing process (hence in a a shared data plane, no provider routing info is exchanged, see table. Therefore, sharing has also impact on:— latency— availability of the connection, (as the MTBF depends on the length of the

connection):— performance (in the case of transparent optical L1VPNs)

On the other hand, availability of resources can be guaranteed only on the level of probabilities. This probability is agreed upon in the SLA (e.g. as BHCA = busy hour call attempts). Penalties are fixed for the case when the statistical value can not be met by the operator in an agreed time interval.

The network operator must try to meet the SLA by providing a reasonable basis of resources. The planning process must take into account a predicted user behaviour, the cost for resources and penalties.

Can be used to classify the scenarios


Scenario: Overlay Model

UNI

Customer 2 Customer 1

UNI

Customer 2

UNI

Customer 1

is connected to

can connect to

has visibility

UNI-C based VPN



Restriction of Management Visibility: — management view only on resources that have been ordered /are under

service contract

Restriction of reachability:— only nodes within the user group (VPN-internal) can call each other— only calls from nodes within the user group (VPN-internal) are acceptedor:- outgoing access to VPN-external destinations- incoming access from VPN-external sources

Generally— One contract, one Service Level Specification, one bill,...

Management requirements / CP requirement— needs to be configured— needs to be policed (whitelist …)

• Implementation issue: where is this done in the CP? CAC?— Add new member— Change address of member?— Configure policy

VPN as a Closed User Group (CUG)



UNI

Domain

Customer 2

Domain

Customer 1

UNI

Customer 2

UNI

Customer 1

Network Operator Domain

CNM

Customer 1

NMS NetworkOperator

NMI („X“)

VPN as a (CUG)

SLA



Implementation effort comparatively low— UNI required— PE must implement mapping of private (CPI) addresses, if these are used in the — Implementation and configuration of policing functions within provider network

Membership information needs to be distributed offline and configured manually in the CEs.

Acceptable, if customer network is static (e.g. customer network may mainly consist of L2 and L3 devices. This may be the normal case)

Resilience features can be used as far as they are supported by the UNI (UNI2.0)

Dynamic services.

Assessment


Scenario: Overlay Extension Model

Implementation effort higher compared to Overlay Model— UNI required— PE must implement mapping of private (CPI) addresses, if these are used in the — Implementation and configuration of policing functions within provider networkPlus:— BGP— BGP VPN Discovery

attractive only, if network structure is highly dynamic

Assessment

} additional effort


Scenario: Virtual nodeDescription

GMPLS enabled

BB

“Virtual Node”

CD

CD

CD CD

CD CD CD

CD

CD

CD

CD

CD CD

CD CD CD

CD

CD

CDCD

Views on the NW:

NW:

One Routing Domain

CE

CE

CE

CE


General Scenario: Two Providers in parallelDescription

CD

CD

CD CD

CD CD CD

CD

CD

NW:

CE

CE

CE

CDCE

Provider1

Provider2

•Scenario supported by any L1 transmission scheme.•leased line•dynamic leased line•overlay / extended overlay•virtual node, virtual link•per VPN Peer


Scenario: Virtual node

Implementation effort higher— UNI required— PE must implement mapping of private (CPI) addresses, if these are used in the — Implementation and configuration of policing functions within provider network— BGP— BGP VPN DiscoveryPlus— Protocols providing transport of customer routing information

attractive only, if — real time dynamic services are required— network structure is highly dynamic and — CP routing is used in the L1VPN domain as a whole (see previous slides)

attractive for carriers carrier not needed by broadcasters

Assessment

} additional effort


Scenario: Virtual linkDescription

NW:

virtual link topologydistributed via routing protocols

PD

PD

PD PD

PE

PDPD

PDPD PD

PD

PD PD

PD PDPD

PD

PDPD

PD

PD

PE

PD

PD

PE

PE

PE

PE

PEPE

PE

Routing info exchange on: CE-PE links remote customer sites virtual links TE link attributes

(abstraction of the provider NWdetermined from data link properties)

CEPE

CE data link resources exclusively allocated to virtual link/VPN

TE Link attributes e.g.:• latency• performance• shared risks


Scenario: Virtual link

Dedicated resources— scheduling can be performed internally, resources always guaranteed by

provider— effect of resource sharing smaller than in overlay and virtual node.

Properties of links known and distributed via routing protocols— Customer has all knowledge to configure properties of e2e-connections

• availability• performance• latency …

— SLA on basis of links?— Less sharing of operation and management infrastructure— Integration of provider network via CP protocols possible.

Attractive for broadcasters for scheduled applications, where100% call success is required.

Attractive for guaranteed availability, latency for SANs, performance for live events (jitter)

Assessment


Scenario: Per VPN PeerDescription

NW:

virtual link topologydistributed via routing protocols

PD

PD

PD PD

PE

PDPD

PDPD PD

PD

PD PD

PD PDPD

PD

PDPD

PD

PD

PE

PD

PD

PE

PE

PE

PE

PE

PE

Routing info exchange on: CE-PE links remote customer sitespartition portion of provider NW:

virtual links with TE attributes virtual nodes

CEPE

CE data link resources exclusively allocated to virtual link/VPN

TE Link attributes e.g.:• latency• performance• shared risks

PE

PD

virtual node


Scenario: Per VPN Peer

Dedicated resources—scheduling can be performed internally, resources always

guaranteed by provider—effect of resource sharing smaller than in overlay and virtual node.

Properties of links known and distributed via routing protocols—Customer has all knowledge to configure properties of e2e-

connections• availability• performance• latency …

—SLA on basis of links?—Less sharing of operation and management infrastructure—Integration of provider network via CP protocols possible.

Effort higher without added value, may be reasonable only for large networks or critical parameters.

Assessment


Scenario: Management based model

If there is no explicit need for near real-time provisioning of connections, management based service models are the better choice: easier to implement setup functionality (is a subset of management functionality of the provider) easier to implement mapping of private names to public names (can be done in one database) easier to implement policing (only one interface has to be policed and compared with the SLA) easier to implement security (only one interface has to be supervised, standard technology) easier to provide value added management functionality such as advanced management functionality (see benefits). easier to offer outsourcing (as the customer view is a subset of the operator’s view).

Assessment


Summary

VPN features are:— virtualization of resources— virtualization of operation -> outsourcing

Virtualization of resources:— high technical effort by CP— trade-off between resource spending and penalties difficult due to unknown user

behaviour— only acceptable for customers, if no special requirements regarding latency , security,

..

Virtualization of operation is attractive for customers— Sharing of management system infrastructure— sharing of operational support— less attractive the higher the functionality provided by the network is …— … can be achieved by management as well

…. make it simple !!! start with management

Shared data plane vs. dedicated data plane


Requirements for Broadcasters

Management— Detailed billing, potentially allocation to specific, broadcaster internal

projects— Integration with electronic order management.— Fluctuation of nodes without new SLA negotiations with operator low

Topology: — Integration of quasistatic star-shaped network connecting the local

studios with the headquarters of the “Landessender”— Transfer to satellite uplinks and DVB-T transmitters.— Dynamic for broadcast production house— Potentially in future:

• Video on demand• SAN-like applications for internal production purposes (archive for movies).

Management and Topology


Requirements for Broadcasters (ctd.)

Requirements for these applications — Resilience— Latency— Performance (BER, ES, …)— Performance (SNR …) for transparent networks— Scheduling

• 100% call establishment success (for live events)• call establishment success < 100% (for production; file based)• LAN-WAN-connection

Presumably, broadcasters do not have the requirement to interconnect several medium or large L1 networks

Requirements


Requirements for Broadcasters (ctd.)

Business Model— Broadcasters buy:

• own equipment • lease fibers on long term from different providers• outsource operation to small providers; CPEs from this operator

— Alternative solutions based on VPNs must provide benefits for broadcasters concerning

• cost structure• flexibility• performance• ease of interfacing to existing production control systems on the broadcasters' side

Scenarios— CUG: incoming calls from post production studios — Outgoing calls to post production studios and co-operating broadcasters

Make it easy - listen to the broadcasters' needs and try to accommodate utilizing a re-usable solution

Business model and scenarios

} should be easy to handle

===!"§ Deutsche Telekom Innovation Center Deutsche Telekom AG Innovation Center Scenarios for...

Documents

Transcript of ===!"§ Deutsche Telekom Innovation Center Deutsche Telekom AG Innovation Center Scenarios for...