1 / 16

Service-oriented transport networking architecture (SOTNA) - proposal, ver.02

Service-oriented transport networking architecture (SOTNA) - proposal, ver.02. NOBEL WP4, Paris meeting 2005-09-26 Håkon Lønsethagen, Telenor R&D. Some background (1).

nerys
Download Presentation

Service-oriented transport networking architecture (SOTNA) - proposal, ver.02

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service-oriented transport networking architecture (SOTNA) - proposal, ver.02 NOBEL WP4, Paris meeting 2005-09-26 Håkon Lønsethagen, Telenor R&D -

  2. Some background (1) • This presentation follows up the Munich presentation, this is, this is a first attempt to establish a Next-generation transport network architecture, with inspiration from the NGN (e.g. ETSI) effort. • Service plane (SP) as a functional block has been avoided, we should try to use more descriptive names on well-defined functional blocks • We should distinguish the logical architecture from (several possible) physical architectures (some examples are given) • It is important to distinguish end-user applications residing in hosts, management applications residing in management systems, and potential control and management applications residing in a CE (Customer Edge Node) • Both UNI and USI (see below) has been included as they may co-exist. However, the division of responsibility should be analysed from case to case • The UNI should not be functionally extended • The USI should not be functionally overloaded, as the UPI may also provide useful functionality -

  3. Some background (2) • We should not base our architecture on use cases that are already covered by “the NGN” architecture. E.g. Video On-demand ??? – unless we want to extend an NGN architecture for offering IP-based services to also have the NGN architecture to offer GMPLS-based services • My assumption is that we will rather (as a first step) consider vertical integration between an IP services “NGN” architecture and an GMPLS “NGTN” architecture(See example towards the end) • One should avoid costly functionality as well as costly replication of network and usage state information in numerous PEs • This is a preliminary proposal – to be assessed and elaborated -

  4. Scope of Service TF (Some post-Paris-meeting ideas) • Is it more appropriate to call it:Service provisioning and management TF (SPM TF) • Scope and objectives • Network services and their supporting (management and control) services • E.g. VPN (VPN service is still a network service, also if the request for such a service is based on an abstracted VPN service request • Application services • Possibly yes - Select one or more application services that are closely related and dependent on/to network services, such as “Storage on-demand” • Proposed Objective for the SPM TF • Identify shortcomings of current GMPLS/ASTN architectures and solutions • Given state-of-the-art Service provisioning architectures and solutions for IP services (cf. e.g. NGN and IPsphere), assess their applicability, strengths and weaknesses with respect to GMPLS/ASTN service provisioning, control and management • Analyse and propose architectural alternatives, improvements, extensions and/or adaptations of such architectures and solutions • The following architecture should only be considered as an initial example of how to apply the NGN architecture for GMPLS/ASTN • This is – to be assess • The integrations issues raised and their business model assumptions are important to assess -

  5. E-NNI R-NNI S-NNI R-NNI NNI-T NNI-T NNI-T E-NNI I-NNI UNI-T UNI PPI USI MP MP SB/AS CSM NAF RAC SCA RAC SCA RAC SUA CP CP CP CP CP TP TP TP TP TP Service-oriented transport networking architecture (SOTNA) - proposal Client domain Provider/Carrier domain A Provider/Carrier domain B Host UPI EUA M3 M1 M2 NMI-A NMI-T C4 M4 S4 S8 C3 C1 C2 S1 S3 S5 S7 SCP S6 S2 UNI-C UNI-N CCI -

  6. Functional blocks • TP – Transport Plane • CP – Control plane • Signalling, Routing, Policy enforcement • NAF – Network Attachment control Function • Dynamic provision of (IP or other TP) address and other CE configuration parameters (e.g. using DHCP) • CE authentication, prior or during the address allocation procedure • Authorisation of network access, based on user profile • Access network configuration, based on user profile • (Location management) • Inter-carrier and inter-domain session border control functionality has so far not been pointed out as such in the architecture -

  7. Functional blocks • SUA – Service User Agent • Initiating the transport service request • E.g. base on TE or other management capabilities in the customer network, CSM (or customer NMS), or possibly CE (however, in the later case it is more likely that the CE will use the UNI) • E.g. based on (transport service) request from end-user application • SCP – Service Control Proxy • Service admission control, and authorisation • Service control as delegated by the SCA • E.g. if service is only Metro wide, the SCA does not need to be involved(No inter-carrier issues) • SCA – Service Control Agent • (Like a call agent) • Session aware • Handles activation/modification of transport services, including request for complex services, e.g. VPN resource and QoS related requests • RAC – Resource and Admission Control • Admission control and setting the respective transport service policies • Transport service session aware but application agnostic • Authorises QoS resources and defines the polices that are enforced by the PE and other NEs in the network (possibly on an aggregated basis) • May contain PCE capabilities, this is an interesting topic for further study -

  8. Functional blocks • SB – Service Broker • Brokering between SCA and ASs • AS – Application Server • Offering Value-added services • CSM – Customer Service Manager • Service and customer profile configuration and management • Support management services such as overview of service instances by this customer • E.g. overview and monitoring of VPN service • SLA customer monitoring • EUA – End-user Application • That need transport/communication services -

  9. Reference points • UNI – User-Network Interface (CP) • USI – User-Service Interface • UPI – User-Provider Interface • I-NNI – Internal Network-Network Interface • Out of scope • E-NNI – External Network-Network Interface • (Consider both inter-domain as well as inter-carrier) • R-NNI – Resource and admission control, Network-Network Interface • Consider both inter-domain as well as inter-carrier • S-NNI – Service control, Network-Network Interface • Consider both inter-domain as well as inter-carrier • PPI – Provider Provider Interface (Inter-carrier) • UNI-T – TP User-Network Interface • Out of scope • NNI-T – TP Network-Network Interface • Out of scope -

  10. Physical units/nodes or blocks • CE – Customer Edge Node (Customer Premises Equipment) • PE – Provider Edge Node, often containing both CP functionality (in addition to TP functionality) • Host – A workstation, server, desktop PC, etc. connected to a CE via a local/customer area network • Running the end user application, through middleware and operating system on the host -

  11. NNI-T R-NNI S-NNI R-NNI NNI-T E-NNI E-NNI I-NNI UNI-T UNI PPI USI NNI-T MP MP SB/AS CSM SUA NAF RAC SCA RAC SCA RAC CP CP CP CP CP TP TP TP TP TP Mapping to physical nodes – Example 1 Client domain Provider/Carrier domain A Provider/Carrier domain B Host UPI EUA M3 M1 M2 NMI-A NMI-T C4 S4 S8 C3 C1 C2 S1 S3 S5 S7 SCP S6 S2 UNI-C UNI-N CCI CE PE NE NE NE -

  12. NNI-T R-NNI S-NNI R-NNI NNI-T E-NNI E-NNI I-NNI UNI-T UNI PPI USI NNI-T MP MP SB/AS CSM SUA NAF RAC SCA RAC SCA RAC CP CP CP CP CP TP TP TP TP TP Mapping to physical nodes – Example 2 Client domain Provider/Carrier domain A Provider/Carrier domain B Host UPI EUA M3 M1 M2 NMI-A NMI-T C4 S4 S8 C3 C1 C2 S1 S3 S5 S7 SCP S6 S2 UNI-C UNI-N CCI CE PE NE NE NE -

  13. Vertical integrations between service platforms- E.g. Driven by AN/TN provider, GMPLS capable PE (FFS) • PE – multi-layer switching capable • Base case: PE is here an access network node (metro edge node). Traffic from customers is aggregated and sent to Service edge node (SE) that offer IP services to customers • Case A: Host need a high bandwidth connection, that will be realised directly in the GMPLS network • This is requested by SUA and request is received by SCP/SCA for the IP services network. SCP/SCA decideds that connection should be realised directly by the GMPLS network • SCA signals this to the SCA for the GMPLS network, which checks with its RAC function. If OK, RAC configures PE and initiate an appropriate LSP set-up request, which is handled by the CP of the GMPLS network • Note, in the following scenarios, depending on the business model assumed, the management plane should be split according to the involved domains -

  14. NNI-T I-NNI UNI-T NNI-T UNI I-NNI USI MP CSM NAF SUA TP CP TP CP CP TP TP CP Vertical integrations between service platformsE.g. Driven by AN/TN provider, GMPLS capable PE (FFS) Client domain Provider/Carrier domain A Host UPI EUA SCP/SCAIP nw C4 Sy Sx RACIP nw C3 C1 C2 SCAGMPLS nw RAC IP services network UNI-C UNI-N SE GMPLS services network PE AN -

  15. USI I-NNI NNI-T NNI-T I-NNI UNI-T UNI MP CSM NAF SUA CP TP CP TP CP CP TP TP Vertical integrations between service platformsE.g. Driven by IP Service provider, GMPLS capable PE (FFS) Client domain Provider/Carrier domain A Host UPI EUA SCP/SCAIP nw C4 Sy Sx RACIP nw C3 C1 C2 SCAGMPLS nw RAC IP services network UNI-C UNI-N SE GMPLS services network PE AN -

  16. NNI-T I-NNI I-NNI UNI-T USI NNI-T UNI MP CSM NAF SUA TP CP CP TP TP TP CP CP Unified service platform:IP services and transport Network provider (FFS) Client domain Provider/Carrier domain A Host UPI EUA SCP/SCAIP/GMPLS nw C4 Sy C3 C1 C2 RAC RAC IP/GMPLSservices network UNI-C UNI-N SE/PE AN -

More Related