Docstoc

Document template for NOBEL - Nobel 2

Document Sample
Document template for NOBEL - Nobel 2 Powered By Docstoc
					                            IST IP NOBEL "Next generation
                                                                        Title of the document
                            Optical network for Broadband
                                 European Leadership"               d3b95c2d-c84f-4997-a686-
                                                                          166859b24a5d.doc




Work Package 1
Deliverable 30
“Definition network scenarios and solutions
supporting broadband services for all”

Status and Version:             Draft
Date of issue:                  31.12.2005
Distribution:                   Project Internal
Author(s):                      Name                        Partner
                               Andrea DI GIGLIO             Telecom Italia LAB (editor)
                               Jesús F. Lobo                Telefónica I+D
                               Juan Fernández-Palacios      Telefónica I+D
                               Víctor López                 Telefónica I+D
                               Ángel Ferreiro               Telefónica I+D
                               Bela Berde                   Alcatel Research & Innovation
                               Anders Berston               Acreo
                               Ilse Lievens                 IMEC
                               Wouter Tavernier             IMEC
                               Jurgen Baert, ,              IMEC
                               Marc De Leenheer             IMEC
                               Bart Dhoedt                  IMEC
                               Tiziana Ferrari              INFN
                               Salvatore Spadaro            UPC
    Checked by:




Table of Contents
1    Introduction [TILAB]                                                                 3
     1.1   Purpose and Scope                                                              3
     1.2    Reference Material                                                            3
        1.2.1 Reference Documents                                                         3
        1.2.2 Acronyms                                                                    6




                                         Page 1 of 48
                                IST IP NOBEL "Next generation
                                                                          Title of the document
                                Optical network for Broadband
                                     European Leadership"             d3b95c2d-c84f-4997-a686-
                                                                            166859b24a5d.doc




    1.3      Document History                                                               6
    1.4      Document overview                                                              6
2   Statement of the problem                                                                7
    2.1      Introduction                                                                   7
    2.2    Applications requirements and network services (drivers)                         8
       2.2.1 Main requirements from applications                                            8
       2.2.2 Traffic& QoS requirements evolution                                           11
        2.2.2.1   European core network                                                    11
          2.2.2.2   Metro networks                                                         14

    2.3    Technology requirements (drivers)                                               15
       2.3.1 Transport Stratum                                                             15
        2.3.1.1  Layer 1                                                                   15
          2.3.1.2   Layer 2                                                                17
          2.3.1.3   Layer 3                                                                17
      2.3.2 Service Stratum                                                                21
       2.3.2.1  Network Services                                                           21
          2.3.2.2   User services: Fixed-mobile Convergence                                25

    2.4    Topology: Constraints and requirements                                          29
       2.4.1 Metro/regional network                                                        29
       2.4.2 Core/backbone network                                                         30
    2.5    Specific applications                                                           31
       2.5.1 Computing Grids                                                               32
        2.5.1.1    Data Movement                                                           32
          2.5.1.2   Data Replication                                                       34
          2.5.1.3   Data streaming coordinated with job execution                          35
      2.5.2 Requirements for consumer and media Grids                                      36
      2.5.3 Storage Area Networks                                                          40
       2.5.3.1  Classification of storage applications                                     40
          2.5.3.2   Storage networking protocols                                           42
      2.5.4 TV – Broadcasting                                                              44
      2.5.5 Video on Demand                                                                45
       2.5.5.1  Traffic Model for VoD service                                              46
          2.5.5.2   Scalability issues of first VoD implementations                        46




                                              Page 2 of 48
                                  IST IP NOBEL "Next generation
                                                                                    Title of the document
                                  Optical network for Broadband
                                       European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                     166859b24a5d.doc




1            Introduction [TILAB]
This deliverable represents the final document that will be provided by the Workpackage 1 of the
IST Nobel project Phase I. Its main goal is twofold:
           To summarize the results reached during two year work, ranging from emerging
            applications requirements through drivers leading the network innovations up to the
            network scenarios from a progressive point of view (short-term, mid-term, long and
            extended long-term scenario)
           To reach the final goal for WP1, that is to define guidelines for network evolution where the
            progressive scenarios might partially co-exist and all the network services can be offered
            as identified in WP1.
The part summarizing the previous deliverables results would be as concise as possible ever
since it repeats some considerations yet contained in other deliverables. Some references to them
might be useful.
This deliverable has to be concentrate on defining some project rules for next generation transport
networks, and in particular on how they can offer the numerous services project partners propose
in previous chapters.
The main issues to face of, having the goal of defining network architectures, might be:
           Topology
           Customers applications requirements
           Available/future network technologies
           Particular architectures/solutions for specific problems, applications, and services


1.1          Purpose and Scope

1.2          Reference Material

             1.2.1 Reference Documents

[1]       Deliverable 12 “Overview of social impact and economic opportunities generated by NOBEL
          concepts”, NOBEL WP2
[2]       Deliverable 21 “Definition of drivers and requirements for core and metro networks
          supporting end-to-end broadband services for all”, NOBEL WP1
[3]       “Enabling Triple Play into the home – The Last Yards” Willem Verbiest, Alcatel, Broadband
          World Forum 2005 – Madrid
[4]       “Architectures-end-to-end video delivery” Texas Instruments , Broadband World Forum 2005
          – Madrid
[5]       Deliverable 17 “Preliminary Report on new methods for route management (intra- and inter-




                                                Page 3 of 48
                             IST IP NOBEL "Next generation
                                                                               Title of the document
                             Optical network for Broadband
                                  European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                166859b24a5d.doc




      domain), and accurate statistical models for evaluating the impact on QoS”, NOBEL WP2
[6]   Deliverable 27 “Final report on Traffic Engineering and resilience strategies for NOBEL
      solutions”, WP2
[7]   ITU-T, Rec. Y.2001, 12/2004
[8]   ETSITISPAN#08Bis. "Considerations on RACS Release 2". Lucent Technologies,TNO
      Telecom, Portugal Telecom, Telefonica I&D, Alcatel, Infineon, France Telecom. Sophia
      Antipolis 24-28 October 2005.
[9]   RFC 1349 “Type of Service in the Internet Protocol Suite” – July 1992
[10] RFC 2474 “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
     Headers” – December 1998
[11] RFC 2475 “An Architecture for Differentiated Services” – December 1998
[12] RFC 2597 “Assured Forwarding PHB Group” – June 1999
[13] RFC 2598 “An Expedited Forwarding PHB” – june 1999
[14] RFC 1752 “The Recommendation for the IP Next Generation Protocol” - January 1995
[15] RFC 2460 “Internet Protocol, Version 6 (IPv6) Specification” – December 1998
[16] RFC2547bis “BGP/MPLS IP VPNs” - October 2004
[17] White paper “Comparing MPLS-Based VPNs, IPSec-Based VPNs, and a Combined
     Approach from Cisco Systems”, Cisco systems 2004
     http://www.cisco.com/warp/public/cc/so/neso/vpn/vpnsp/solmk_wp.pdf
[18] RFC 4026 “Provider Provisioned Virtual Private Network (VPN) Terminology”, March 2005
[19] White paper "VPN TECHNOLOGIES - A COMPARISON", Data Connection Limited,
      February 2003, updated June 2004
      http://www.dataconnection.com/network/download/whitepapers/vpntechwp.pdf
[20] draft-ietf-l3vpn-ce-based-02, “An Architecture for Provider Provisioned CE-based Virtual
     Private Networks using Ipsec”, February 2004
[21] draft-ietf-l3vpn-vpn-vr-02.txt, “Network based IP VPN Architecture using Virtual Routers”,
     April 2004
[22] RFC 4110, “A Framework for Layer 3 Provider-Provisioned Virtual Private Networks
     (PPVPNs)”, july 2005
[23] White paper "MPLS VPNs: Layer 2 or Layer 3? Understanding the Choice", Tim Wu,
     Riverstone Networks, 2002
[24] Presentation "Enterprise Buyer’s Guide to MPLS VPN Services", Dr. Peter J. Welcher,
     MPLScon 18 may 2005
[25] RFC 3809 “Generic Requirements for Provider Provisioned Virtual Private Networks
     (PPVPN)”
[26] RRFC 4031 “Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks
      (PPVPNs)”
[27] IPSec VPN Fundamentals, Pradosh Kumar Mohapatra and Mohan Dattatreya, TechOnLine
     Publicaton, Sept. 19 2002



                                           Page 4 of 48
                             IST IP NOBEL "Next generation
                                                                              Title of the document
                             Optical network for Broadband
                                  European Leadership"                   d3b95c2d-c84f-4997-a686-
                                                                               166859b24a5d.doc




[28] Dynamic Multipoint IPsec VPNs (Using Multipoint GRE/NHRP to Scale IPsec VPNs), Mike
     Sullenberger, Cisco Systems, Aug 13, 2005
[29] Soon-Jin Park et al., “Fiber-to-the-Home Services Based on wavelength-Division-
     Multiplexing Passive Optical Network”, Journal of Lightwave Technology, vol 22, nº 11, pp
     2582-2591, Nov. 2004.
[30] Deliverable 6 “Preliminary definition of drivers and requirements for core and metro networks
     supporting end-to-end broadband services for all”, WP1
[31]
[32] Deliverable 11 “Preliminary definition of network scenarios and solutions supporting
     broadband services for all”, WP1
[33] draft-ietf-l3vpn-as2547-07.txt, “Applicability Statement for BGP/MPLS IP
       VPNs”, Eric Rosen, Oct 2004
[34] draft-ietf-l3vpn-as-vr-01.txt, “Applicability Statement for Virtual Router-
       based Layer 3 PPVPN Approaches”, Ananth Nagarajan, Feb 2004
[35] draft-declercq-l3vpn-ce-based-as-00.txt, “Applicability Statement for
       Provider Provisioned CE-based Virtual Private Networks using IPsec”, Jeremy
       De Clercq, Jan 2004
[36] Foster, I.; Kesselman, C.; Tuecke, S.; The Anatomy of the Grid: Enabling Scalable Virtual
     Organizations
[37] EGEE Middleware Architecture (Release 2); Deliverable DJRA1.4, EGEE-DJRA1.1-594698-
     v1.0, Section 8.2, (http://edms.cern.ch/document/594698)
[38] EGEE Middleware Architecture and planning, EGEE Project Deliverable EGEE-DJRA1.1-
     594698-v1.0, Jul 2005 (https://edms.cern.ch/document/594698/)
[39] Contacting the EGEE Regional Centers (http://egee-sa1.web.cern.ch/egee%2Dsa1/ROC-
     support.htm)
[40] LHC Computing Grid, Distributed Production Environment for Physics Data Processing
     (http://lcg.web.cern.ch/LCG/)
[41] Curti, C.; Ferrari, T.; Gommans, L. et alt.; On Advance Reservation of Heterogeneous
     Network Paths, Future Generation Computer Systems Journal Vol. 21 Issue 4 (2005), pp.
     525-538.
[42] Specification of Interfaces for Network Performance Monitoring, EU Deliverable DJRA4.2,
     EGEE Project (https://edms.cern.ch/file/533215/2/EGEE-DJRA4.2-533215-v1.1.pdf), Jan
     2005 Grid Network Services Use Cases
[43] Network Measurement Working Group, Global Grid Forum
     (https://forge.Gridforum.org/docman2/ViewCategory.php?group_id=63&category_id=513)
[44] Ferrari, T.; Kavoussanakisy, K.; Palansuriya, C.; Patilz, A.; Ronchieri, E.; Agreement
     Signalling and Network Service Provisioning for Grids; 2nd International Workshop on
     Networks for Grid Applications (GridNets 2005), Boston, USA, Oct 2005
[45] Ferrari, T. et alt.; Grid Network Services Use Cases; Version 2.9 , work in progress, Grid
     High-Performance Networking WG, Global Grid Forum, Aug 2005
     (https://forge.Gridforum.org/docman2/ViewCategory.php?group_id=53&category_id=750)
[46] International VLBI Service for Geodesy and Astrometry (http://ivscc.gsfc.nasa.gov/).




                                          Page 5 of 48
                              IST IP NOBEL "Next generation
                                                                                Title of the document
                              Optical network for Broadband
                                   European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                 166859b24a5d.doc




           1.2.2 Acronyms
ASON          Automatic Switched Optical Network
ASTN          Automatic Switched Transport Network
CE            Computing Element
DiffServ      Differentiated Services
GridFTP       Grid File Transfer Protocol
E-NNI         External Network-Network Interface (both inter-carrier and intra-carrier)
LFN           Logical File Name
LRMS          Local Resource Management Service
NSAP          Network Service Access Point
NRN           National Research and education Network
QoS           Quality of Service
SE            Storage Element
SLA           Service Level Agreement
SURL          Site URL
TMF           Telemanagement Forum
TURL          Transport URL
UNI           User to Network Interface
VPN           Virtual Private Network
VO            Virtual Organization
WAN           Wide Area Network



1.3        Document History

Version                  Date                      Authors                    Comment
0.01                     09/11/2004                WP1                        ToC




1.4        Document overview



                                            Page 6 of 48
                                    IST IP NOBEL "Next generation
                                                                                           Title of the document
                                    Optical network for Broadband
                                         European Leadership"                          d3b95c2d-c84f-4997-a686-
                                                                                             166859b24a5d.doc




2        Statement of the problem

2.1      Introduction
Network designers make a strong distinction between two sorts of elements - those that are ‘in’
the network and those that are ‘attached to’ the network. The main goal of this deliverable will be
the definition of technical guidelines and rules allowing operators to design cost effective core and
metro networks as well as to provide the network services as defined in NOBEL. In order to define
these guidelines, it is necessary to know the current situation and expected evolution of the
following key issues related to core and metro networks:
     Network requirements derived from emerging applications
     Development of network services along the time
     Available technologies for transport and network services provisioning
     Problems related to particular applications
The primary issue of the end-to-end reasoning in NOBEL is the assurance of accurate and reliable
transfer of information across the network. A top-down methodology has been used to derive
network requirements and guidelines for their design from applications and services considered to
work as drivers in the future according to the scheme of Figure 2.1


                  Applications like VoD        For exemple.: Rings substituted by
                     genete traffic                  mesh networks.



                      TRAFFIC
                                                  ARCHITECTURE
                     EVOLUTION
                                                  MODIFICATIONS
                                                                                    ADVANCED
                                          +                                         NETWORK
                      DEVICES                     CONTROL PLANE
                    AVAILABLITY                   DEVELOPEMENT
                    I

                    ROADM, OxC, etc.            More distributed intelligence



               Figure 2.1: Traffic and technology driven evolution of networks.




To this end, as a first step, a traffic evolution forecast for different types of applications and QoS
requirements will be provided in order to show in what direction the network should evolve. As
described in D6, in this first phase NOBEL follows the ITU Recommendation Y.2011, which
introduces two strata for the functional description of the network: Service and Transport Stratum
(Figure 2.2).




                                                Page 7 of 48
                             IST IP NOBEL "Next generation
                                                                                      Title of the document
                             Optical network for Broadband
                                  European Leadership"                            d3b95c2d-c84f-4997-a686-
                                                                                        166859b24a5d.doc




                                                             Management Plane
                                                              Control Plane
                                                             User Plane


                                        NGN Service Layer


                                                             Management Plane
                                                              Control Plane
                                                             User Plane


                                       NGN Transport Layer


               Figure 2.2: Functional schematic of the network infrastructure.


In this chapter, we will briefly identify the main technologies in both the transport and service
stratum that are currently available or to be developed in the future.
 The Transport stratum interconnects users and/or service nodes. In this section we will pay
  special attention on transparency issues.
 The Service stratum provides the users with services. It uses the transport layer to build
  services up (e.g., connectivity). From the NOBEL perspective two kinds of services can be
  defined for the service stratum:
      User services: Humans can use these services (e.g., web services, telephony, video
       conferencing, and video on demand). They are also referred to as “applications”. These
       services relay on the
      Network services: These services provide connectivity to the user and are deeply
       described in D21. This connectivity is used by user services, as telephony. In this chapter,
       we will provide the main technologies that allow the provision of the network services
       defined in NOBEL (i.e. L1 VPNs, L2 VPNs, L3 VPNs, Public&Business IP).
Finally, we will investigate the problems involved in nowadays implementations : Grid applications,
TV broadcast, Storage Area Networks, and Video on Demand.


2.2     Applications requirements and network services (drivers)

         2.2.1 Main requirements from applications
Applications requirements were deeply explained in D6 and D21. Let us briefly review the
characteristics of the network service according to the applications to be carried out:

                       Table 2.1: Classification of types of applications
                  \ BW
                                  Low                  Medium                         High
              QoS \
                             Legacy and IP                                      Video conference,
           Real time                                    Gaming
                               telephony                                         Grid computing
                                                  Remote backup,                  TV and Video
          Streaming              UMTS
                                                 network supervision               Broadcast




                                           Page 8 of 48
                             IST IP NOBEL "Next generation
                                                                                          Title of the document
                             Optical network for Broadband
                                  European Leadership"                                d3b95c2d-c84f-4997-a686-
                                                                                            166859b24a5d.doc




         Transactional           e-buy                      Telnet                        SAN

                            e-mail, domotics,          p2p file exchange,
          Best Effort                                                                     VoD
                                  VoIP                  Data acquisition


Where QoS categories are defined, in turn, as follows:

                            Table 2.2: Definition of QoS parameters
                             Blocking       Network  Set up            Mean              Packet
                            probability availability time              delay            loss rate

            Real time         < 0.1%        > 99.99%         <1s            *            < 5 E-5

            Streaming         < 0.1%            > 99.9%      <1s            *            < 1 E-3

            Transactional      < 1%             > 99.9%      <3s       < 200             < 1 E-2
                                                                        ms
            Best Effort          *                 *           *            *               *


Since network services can also be analyzed from the resilience point of view (QoR), the following
table must be considered as well:

                             Table 2.3: Definition of QoR classes

   Resilience class           Recovery time                   Bandwidth guarantee
           High                       < 100 ms                                 Yes

       Medium high              100 ms <  < 1s                                 Yes

       Medium low               100 ms <  < 1s                                 No

           Low                          > 1s                                   No



Obviously, there is a straightforward correspondence between Table 2.2 and Table 2.3 as
represented by Figure 2.3, that also maps applications requirements. A possible standardization of
QoS could be obtained this way through the simplified Table 2.4




                                            Page 9 of 48
                                         IST IP NOBEL "Next generation
                                                                                                  Title of the document
                                         Optical network for Broadband
                                              European Leadership"                          d3b95c2d-c84f-4997-a686-
                                                                                                  166859b24a5d.doc




                                                          Real
                                                          Time
            Strict QoR


                                                                          telemedicine
                                                                          applications
                                                                                     Emergency Class

                                     Bank transfers,                Conversational Class
                                    transaction data
                                                              Business VoIP        Video
                           Prioritized Elastic Class
                                                                                   conferencing
             Loose QoR




                                                       Streaming Class
                           e-mails
                             or
                           ftp traffic
                                                                    Streaming
                          Best Effort Class                         media

                         Loose QoS                                                Strict QoS


                Figure 2.3: The QoS and QoR requirements of various applications


                           Table 2.4: Relationship between QoS and QoR classes

                                           Real                          Streamin      Interactive       Best
                                           Time                          g             data              Effort
             QoS                    Emergenc    Conversation                           (Transactional)
 Resilience class                   y           al
 class           Hig                      X                  X
                 h
          Medium                                             X                X
          high                                                                X               X
           Medium
           low                                                                                X              X
                  Lo
                  w


As an example of how applications requirements and network services are linked and are on the
basis of guidelines for network design, one may think of security, a critical property for some
applications. Security is a broad term, including a number of different types of functionality, such
as confidentiality, integrity, authentication, authorization, non-repudiation, etc. In this context, we
restrict the scope to confidentiality. Privacy can be supported through application-level
mechanisms, such as encryption based on public or private keys. However, encryption is a
compute intensive process that can penalize the overall performance of applications during the
entire data transfer time span. Conversely, network technologies supporting traffic isolation are
initially affected by higher configuration latencies, but can ensure higher data transfer throughout
in the long term.




                                                       Page 10 of 48
                              IST IP NOBEL "Next generation
                                                                                  Title of the document
                              Optical network for Broadband
                                   European Leadership"                       d3b95c2d-c84f-4997-a686-
                                                                                    166859b24a5d.doc




         2.2.2 Traffic& QoS requirements evolution

The objective of this section is to evaluate how the expected traffic evolution might impact on the
QoS requirements of core and metro networks. So, a traffic forecast, mainly based on WP2 results
in D27 [6], will be provided in order to estimate how much is the traffic generated in the short,
medium and long term by the classes of applications with different QoS requirements.

                       2.2.2.1 European core network
NOBEL project has analyzed core networks from several angles. In this section we collect the
information in different deliverables to estimate the proportion of traffic due to the different classes
of services in the reference European core network used in WP2. [6]
In the questionnaire of D12 [1], NOBEL partners were asked about the evolution of network
infrastructures, according to their opinion, Internet access penetration in households could be
increased from 39% in 2004 to 67% in 2015. This growth will be higher in broadband access
penetration. As described in [1], broadband deployment will favour a traffic growing due to either
the introduction of new users and the use of high bandwidth demand by new applications.
Broadband users are much more motivated to use bandwidth-intensive Internet applications such
as sharing computer files, watching video clips or downloading games, pictures and videos. As
described in D12 [1], the majority of residential traffic is expected to be generated by two main
multimedia network applications: peer-to-peer and video multicast (especially IPTV, Video on
Demand and HDTV). In Broadband World Forum 2005, Alcatel [3] showed the typical residential
connection to Internet:

                       Table 2.5: Expected typical residential connection
                                                  Downstream Upstream
                         2 HDTV channels          16 Mbps          256 kbps
                         Gaming channel P2P       1 Mbps           1 Mbps
                         2 Voice calls            32 kbps          32 kbps
                         High Speed Internet      3 Mbps           512 kbps
                         Total                    20 Mbps          2 Mbps


According to the applications distribution in this connection, most of the traffic in Internet will be
due to video applications. Furthermore, in the Broadband World Forum 2005, Texas Instruments
[4] forecast that IPTV Market will be 1/3rd of the digital market by the end of the decade. There is a
wider analysis about multimedia applications in D21[2], that also forecasts a great increment in
Internet multimedia market.
Although the increase of data due to video applications is a widely accepted idea, our analysis is
focused on core networks and we have to analyse this particular situation. Core networks will not
have to support so much multimedia traffic as metro networks. The main reason is that core
network only will distribute the content for the regional distribution servers, located in metro
network [2]. Besides, the QoS required for this distribution may not have to be streaming or real



                                            Page 11 of 48
                                                   IST IP NOBEL "Next generation
                                                                                                       Title of the document
                                                   Optical network for Broadband
                                                        European Leadership"                      d3b95c2d-c84f-4997-a686-
                                                                                                        166859b24a5d.doc




time classes, because the distribution server could store the content time enough before serving it
to the customers.


Another important data source is business IP traffic. As it was described in D12 [1] in a forecast of
revenues of data services provided by the Yankee Group, business usage of broadband services
such as VPNs and VLANs is expected to grow steadily. This opinion is corroborated by partners’
answer to the questionnaires in D12.


Nowadays the most important traffic source is the P2P programs, as described in the traffic
characterization carried out in D17 [5]. Besides in D12 [1] there is a figure with the traffic observed
in a transit router and 62,4 % of the traffic is due to P2P applications. There no reason to think that
P2P traffic will have a less importance in core networks in the future. Currently new P2P streaming
programs are appearing as a new way to serve contents between the users, like PPlive. These
programs allow users to share multimedia content that they receive in their TV. Maybe P2P
programs will be used as a low-cost way for TV channels to provide contents by streaming and/or
network operators could send them to the customers using a streaming QoS.


Two traffic forecasts has been developed until 2008 in European core network in D27 [6], one
conservative and another progressive. We will use in this document the progressive forecast
studio, although a similar analysis could be done with the conservative one. Using the same tool
than in D27 [6], the progressive forecast has been developed until 2015, dividing the traffic among
voice traffic, business IP traffic and residential IP traffic (Figure 2.4).

                                      900000

                                      800000        Residential IP Traffic
                                                    Business IP Traffic
                                      700000
                                                    Voice Traffic
               Total Traffic (Gbps)




                                      600000

                                      500000

                                      400000

                                      300000

                                      200000

                                      100000

                                          0
                                               2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015



                                                    Figure 2.4: Traffic evolution forecast


Now, we will analyze the distribution of this traffic in the different applications. Main objective in
this section is, not only reach the traffic evolution in European core network, but also estimate the
distribution of this traffic among the different kinds of applications. Instead of distribute traffic
among applications, we will distribute it among the four QoS classes described in the Table 2.1.



                                                                    Page 12 of 48
                                               IST IP NOBEL "Next generation
                                                                                                          Title of the document
                                               Optical network for Broadband
                                                    European Leadership"                            d3b95c2d-c84f-4997-a686-
                                                                                                          166859b24a5d.doc




Based on the arguments described in this section, we estimate proportion of traffic split into the
four QoS classes in Table 2.6. Best Effort traffic is currently main type of traffic and it will be the
main important source of traffic until 2015. Proportion of transactional traffic has decreased in the
latest years because the increase of the best effort traffic due to P2P programs. Transactional
traffic will not increase very much, because of the high Internet penetration in business. However,
penetration of not very extended applications (like SAN) can increase percentage of transactional
traffic. Streaming and real time classes are not very important nowadays, but the video
applications will need these QoS. The amount of traffic due to video applications (IPTV, VoD and
HDTV) will change the traffic proportions in the current networks, increasing to a large extent
traffic proportion because real time and streaming classes. However, this fact will not affect greatly
in core network. In 2015 streaming applications (like IPTV, VoD, etc) and real time (VoIP,
VideoConference) will not have a great importance in European core network.

                                                  Table 2.6: QoS traffic proportion
                                               Best Effort   Transactional        Streaming   Real Time
                                    2002           60,00%                40,00%       0,00%       0,00%
                                    2005           65,00%                35,00%       0,00%       0,00%
                                    2008           60,00%                39,00%       1,00%       0,00%
                                    2010           55,00%                41,00%       3,00%       1,00%
                                    2015           50,00%                43,00%       5,00%       2,00%




If we join the traffic evolution in the reference European core network in the Figure 2.4 with the
traffic evolution estimation and the traffic proportion of each QoS classes (Table 2.6), we can
create a figure with the traffic evolution split into the four QoS classes:



                                    900000
                                    800000          Real Time
                                    700000          Streaming
                                                    Best Effort
                   Traffic (Gbps)




                                    600000
                                                    Transactional
                                    500000
                                    400000
                                    300000
                                    200000
                                    100000
                                           0
                                                   2003           2005        2008        2010      2015



                                      Figure 2.5: Europe core traffic evolution forecast




                                                                  Page 13 of 48
                             IST IP NOBEL "Next generation
                                                                                            Title of the document
                             Optical network for Broadband
                                  European Leadership"                                d3b95c2d-c84f-4997-a686-
                                                                                            166859b24a5d.doc




                     2.2.2.2 Metro networks
Video distribution (e.g VoD and TV) will pressure the traffic in the metro network. Depending on
how VoD is distributed, whether subscribers Set Top Boxes (STB) are provided with memory
enough as to store a complete video and other considerations (see Sec. Error! Reference
source not found.3.4.4 for more details), as well as the number of IPTV channels and whether
there is one or more HDTV channel, traffic expectations may vary but it is generally accepted that
it will grow at exponential rates.
Metro network traffic can be analysed into two components, namely metro-core and metro-access
segments (see [2]). Figure 2.6 shows a possible evolution for Madrid metro network traffic on the
assumption of optimistic VoD penetration. The slope of the curve will depend strongly on whether
VoD penetration is lower or HDTV channel are delivered, etc. (cf. [29]).


                    100000                           10000

                     10000
                                                     1000
                     1000
                                                     100
                      100
                                                                    Metro-core netw ork
                                                     10
                       10                                           Metro-access netw ork

                        1                            1
                             2005


                                    2007




                                              2010




                                                             2015




                 Figure 2.6: Traffic forecast (Gb/s) for Madrid metro network


In section Error! Reference source not found.3.4.4, metropolitan evolution scenarios will be
analysed at three steps, for short term (2007), medium term (2010) and long term (2015). We will
review it according to the case study of Madrid previously presented (in [2]) and analyse the
scenarios from a techno-economic point of view.




                                           Page 14 of 48
                             IST IP NOBEL "Next generation
                                                                               Title of the document
                             Optical network for Broadband
                                  European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                166859b24a5d.doc




2.3     Technology requirements (drivers)
This section describes the requirements coming from the network infrastructure’s evolution. Today
the network architecture accommodates a wide variety of network technologies, radically diverse
edge devices, spans an enormous gamut of speeds, supports a broad range of applications,
withstands a substantial number of failures, and scales to a large number of nodes. As a result, it
is now widely believed that the transport network architecture is in need of substantial
technological change. The challenges posed by emerging service requirements as well as network
evolution drivers need for consensus, which is often damaging. Not only an agreement among the
many providers is hard to reach, it also poses interoperability issues and may also remove any
competitive advantage from architectural innovation.
There is growing interest in new architectural approaches, while facing serious challenges, from
improving the security and robustness of the core packet delivery service, through accommodating
an explosion in the number and diversity of devices that connect to it, for enabling a new
generation of applications. A network architecture - comprising the data plane, control plane, and
management plane - is a subtle thing that defies rigorous analysis or satisfying simulation, and is
best understood through extensive live experimentation.
The main - most stringent - limitation in Internet today could be shortly summarized as:
      Edge diversity constraint: The Internet originally assumed host computers were connected
       to the edges of the network, but host-centric (static device) assumptions are not
       appropriate anymore today with an increasing number of mobile devices.
      Application requirements constraint: Internet originally provided only a best-effort packet
       delivery service, but there is value in enhancing (adding functionality to) the network to
       meet application requirements (consider, for instance, Grid applications).
Deriving concrete network architecture evolution guidelines from these high-level constraints is not
suitable. However, they give important indications on what are the multiple network-wide (even
end-to-end) objectives, we have to consider as a priority for next-generation, highly automated
networks.
There are several key architectural concepts that we expect to play a central role in the design of
the future networks in both the metro and backbone segments:
      Service/architecture neutrality.
      Simplification in network control and management.
      Synergy and convergence among architectural visions.


       2.3.1 Transport Stratum
This section includes the description of current and emerging (under deployment) technologies for
transport networks, related problem, and expected evolution.

                      2.3.1.1 Layer 1
In a transparent network no O/E/O conversions are made and the signal is kept in the optical
domain. One important reason for reducing the number O/E/O conversions and increasing the
optical transparency of metro and core networks is that this may lower the cost. In traditional
opaque networks, O/E/O conventions take place in transponders in the switching nodes of the



                                          Page 15 of 48
                             IST IP NOBEL "Next generation
                                                                               Title of the document
                             Optical network for Broadband
                                  European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                 166859b24a5d.doc




network. In the case transit traffic the O/E/O conversions and the electrical switching could
potentially be (statically) by-passed. Some benefits of this would be:
     Reduction of a major cost mass.
     Improved network reliability with less number of electronic boxes.
     Less power consumption with less number of electronic boxes.
     Less cooling requirement in stations with less number of electronic boxes.
Further benefits and cost advantages may be gained if connections through the network can be
automatically provisioned. A network capable of automatic provisioning of optically transparent
connections is called a Switched Transparent Optical Network. Benefits with automatic
provisioning include an improved overview and control of connections, which together with an
increased flexibility potentially lead to improved usage of network resources. Compared to
manual provisioning, automatic provisioning may also increase the reliability.
In the transparent network layer the routing of the signal is based on the wavelength and/or on the
physical port of the signal. Framing takes place at the ingress to the optically transparent domain.
Framing adds overhead information that makes it possible to detect errors that have occurred
during transmission. Each standardized format has a specific frame and at the ingress to an
optically transparent domain several different frames are possible, e.g. Ethernet frames, STM
frames, and G.709 frames.
ITU has standardized a control plane architecture, called Automatically Switched Optical Networks
(ASON) for Automatically Switched Transport Networks (ASTN), which is also applicable in the
case of optically transparent networks. IETF is standardizing an IP-protocol based control plane
for optical networks called Generalized Multi-Protocol Label Switching (GMPLS) that complements
the ASON architecture. The GMPLS protocols have been prepared for handling the transparent
network layer by including definition of switching nodes (interfaces) that forward the signal based
on wavelength or physical port called Lambda Switch Capable (LSC) and Fibre Switch Capable,
respectively. Switching entities in the GMPLS framework are called Label Switched Paths, and in
this context a transparent network would be capable of carrying and switching LSPs with lambda
and/or fibre encoding type. The client layer of the LSPs is determined by the framing that takes
place at the ingress of the transparent domain (it may be e.g. Ethernet, SDH, OTN, or Fibre
Channel).
One strategy for the introduction of transparency and flexibility is to let it grow gradually inside
existing networks. In a fist step the network can be invented for identifying nodes where the
transponders and electrical switching at some wavelengths can be (statically) by-passed. As new
connections are requested they are established with all-optical through-node-connections. The
transparent layer can at a later stage be made dynamic by introducing flexible transparent
elements such as optical-cross connects in the switching nodes. A green-field scenario where a
Switched Transparent Optical Networks are installed without integrating legacy equipment is also
of course possible.
On the other hand, the SDH/SONET is a circuit switching technology and is applicable to both
metropolitan and core networks. It is well-understood, mature and standardized. Since it was
initially designed to optimize transport of 64-kb/s-based TDM services, a rigid capacity of payload
as well as a coarse fixed-rate multiplexing hierarchy was defined. Today, SDH/SONET systems
are built with bit rates as high as 10 Gbit/s (STM-64/OC-192), with 40 Gbit/s (STM-256/OC-768)
on the horizon. Current SDH/SONET core networks have a switching granularity of VC-4/STS-3.
By the use of Virtual Concatenation (VC) procedure, SDH/SONET may be improved to better
meet today’s requirements, e.g., various switching granularities. Virtual Concatenation allows



                                          Page 16 of 48
                             IST IP NOBEL "Next generation
                                                                               Title of the document
                             Optical network for Broadband
                                  European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                166859b24a5d.doc




flexible concatenation of several SDH/SONET payloads. It assures an effective use of
SDH/SONET capacity. Virtually concatenated payloads constitute a Virtual Concatenation Group
(VCG). Members of a VCG, as opposed to contiguous concatenation, may not reside in the same
STM-N/OC-N contiguously. As a consequence, members of a VCG may reach the destination
through various routes. Intermediate nodes do not need to handle virtual concatenation. The VC
functionality must be implemented only at path termination nodes. This feature makes it possible
to deploy virtual concatenation on legacy SDH/SONET equipment of existing networks, thus to
smooth transition to enhanced networks. On the other hand, it should be noted that differences in
the delay of an individual concatenated signal may occur due to pointer processing at intermediate
nodes. Compensation of differential delays is handled at the destination node. Another advantage
of virtual concatenation is its ability to divide STM-N/OC-N bandwidth into several subrates. Each
of the subrates may be used for accommodation of a different service. The bandwidth of STM-
N/OC-N may be shared, for example, by both telephone service and data signals. An often-
mentioned example of a practical use of virtual concatenation is Gigabit Ethernet. VC-4-16c (STM-
16) is required to accommodate Gigabit Ethernet signals at full speed under conventional SDH.
However, the capacity of 1.4 Gb/s is then wasted. On the other hand, contiguous concatenation of
four VC-4 containers (VC-4-4c) provides too small capacity to fully accommodate Gigabit Ethernet
signals. The best solution would be concatenation of seven VC-4 payloads and it is possible with
the virtual concatenation.
For many metropolitan areas it seems that there is still some room for resource usage optimization
on the per day basis. Together with the switching capability, capacity of links used by business
customers during the day can be re-used for residential users in the evening. Such a resource
usage optimization at the medium time scale can be achieved at this stage by the use of the Link
Capacity Adjustment Scheme (LCAS) protocol with support of agile management systems. LCAS
is an extension to Virtual Concatenation. It allows the dynamic alteration of bandwidth of
SDH/SONET transport pipes.
The number of concatenated payloads may be increased or decreased at any time without
affecting traffic currently being sent. Moreover, LCAS will automatically decrease the capacity if a
member of a VCG experiences a failure in the network, and LCAS will increase the capacity when
the network recovers.



                      2.3.1.2 Layer 2
      Lucent contribution



                      2.3.1.3 Layer 3

IP generalities
IP has achieved near-universal acceptance as the network protocol of choice for data
communication network. Without any tricks, IP provides only best effort delivery mechanism that
is designed to discard packets during congested conditions. On the surface this would make IP
unsuitable for mission critical or real time applications.




                                          Page 17 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




UDP
UDP is a connectionless layer 4 protocol used together with IP to provide a connectionless,
unacknowledged delivery service to maximize performance over stable networks.
Because UDP lacks an integral flow control mechanism, it requires assistance from the physical
network. In Gigabit Ethernet environments, the supporting flow control might be provided by
802.3x functionality. It enables a link-layer mechanism for preventing buffer overruns and frame
discard.
The lack of acknowledgement presents another issue. Similar to its dependency on external
support for flow control, UDP must assume that its datagrams were received intact or that upper
layer applications will handle delivery failures; on the other hand, ever since it has no need to wait
for acknowledgements, UDP gains a significant performance advantage.

TCP
TCP is required for networks that might be subject to congestion, variable bandwidth, and
latencies that may result in dropped packets.
TCP is a connection oriented transport protocol. Instead of simply pushing data from source to
destination, TCP first establishes a transmission connection between the communicating pair and
imposes a system of acknowledgements to ensure that each transmission arrives intact. TCP also
provides a mechanism to recover from packet loss resulting from failures or network congestion.
Moreover TCP introduces procedures to provide segmentation of messages for handoff to the IP
layer, sequence number to track the transmission of data across the network and a ramping
algorithm to pace the traffic flow. TCP is also capable of error recovering and reordering out-of-
sequence segments.


Security in IP networks
It is possible to enforce the level of security introduced by transmission layer (such as segregation
of traffic, cryptography …) or by application layer (cryptography, authentication,…) with some
mechanism at IP layer.
The most common are:
       IP filtering
       IPSec
Most of the time, packet-filtering is accomplished by using a router that can forward packets
according to filtering rules. When a packet arrives at the packet-filtering router, the router extracts
certain information from the packet header and makes decisions according to the filter rules as to
whether the packet will pass through or be discarded. The following information can be extracted
from the packet header:
       Source IP address
       Destination IP address
       TCP/UDP source port
       TCP/UDP destination port
       ICMP message type
       Encapsulated protocol information (TCP, UDP, ICMP or IP tunnel)



                                            Page 18 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




IPsec adds integrity checking, authentication, encryption and replay protection to IP packets. It is
used for end-to-end security and also for creating secure tunnels between gateways.
IPsec is independent of the current cryptographic algorithms; it can accommodate new ones as
they become available. It works both with IPv4 and IPv6. In fact, IPsec is a mandatory component
of IPv6.

QoS in IP networks
Without a mean of setting data delivery policies, all data within a network infrastructure receives
equal treatment: in a shared network, some applications require more strict enforcement of data
delivery.
In the hierarchy of data delivery, Classes of Services (CoS) are a subset of Quality of Service
(QoS): CoS typically refers to prioritization of different types of data during transport, while QoS
usually also includes higher levels of service such as guaranteed bandwidth and expedited
delivery of data.
At the network layer, the IP datagram header includes an 8-bit Type of Service (TOS) field that
may be used to indicate preference for data delivery class of service. 4 of this 8 bits provide 16
different types of services and RFC 1349 [9] defines only five classes of services:
      Minimize delay
      Maximize throughput
      Maximize reliability
      Minimize monetary cost
      Normal service
Because of the limited interpretation available for TOS bits in setting different classes of services,
the original 8-bit TOS field in the IP header has been redefined by the DiffeServ initiative to
provide greater flexibility. <Tiziana: the TOS bits have been superseded by the DS + CU fields, so
I don’t think the TOS is worth to be mentioned>
DiffServ use the 8-bit TOS of IPv4 header (or the Traffic Class octet if IPv6 is adopted) to enable
64 classes of services to be defined. <Tiziana: I don’t think this is correct. Diffserv uses 6 bits
while the remaining two are unused and actually used to convey ECN code points, as explained
below>
RFC 2474 [10] and RFC2475 [11] specify that the mechanism of class of service is expanded from
simple priority labeling to become a policy-based system.
Class-of-service forwarding decision are made at every node or hop through the network.
The DiffServ field uses six bits to determine the Differentiated Services Code Point (DSCP). This
code point will be used by each node in the net to select the PHB (see the PHB definition below).
The two least significant bits are currently unused and this field is reserved. The value of these
bits is ignored by differentiated services-compliant nodes, when PHP is used for received packets.
Figure 2.7 shows the structure of the defined DiffServ field.




                                           Page 19 of 48
                               IST IP NOBEL "Next generation
                                                                                Title of the document
                               Optical network for Broadband
                                    European Leadership"                    d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




                                       DiffServ Codepoint    Unused


                                   Figure 2.7: The DiffServ Field
Each DiffServ-capable network device must have information on how packets with different
DiffServ field should be handled. In the DiffServ specifications, this information is called the per-
hop behavior (PHB). It is a description of the forwarding treatment a packet receives at a given
network node. The Diffserv Code Point (DSCP) value in the DiffServ field is used to select the
PHB a packet experiences at each node. To provide predictable services, per-hop behaviors need
to be available in all routers in a Differentiated Services-capable network.
DiffServ PHB definitions include assured forwarding RFC2597 [12] and expedited forwarding
RFC2598 [13]. Assured forwarding PHB is facilitates aggregated packet flows by allowing the
administrator to assign bandwidth and buffering guarantees to different traffic types of sources.
Expedited forwarding is a premium service for mission-critical applications or protocols such as
voice over IP that requires small latency and jitter parameters.

Evolution of IP networks

IPv4 addressing scheme, with a 32-bit address field, provides for over 4 billion possible
addresses, so it might seem more than adequate to the task of addressing all of the hosts on the
Internet, since there appears to be room to accommodate 40 times as many Internet hosts.
Apart from address exhaustion, other restrictions in IPv4 also call for the definition of a new IP
protocol:
      Even with the use of CIDR, routing tables, primarily in the IP backbone routers, are
       growing too large to be manageable;
     Traffic priority, or class of service, is vaguely defined, scarcely used, and not at all
       enforced in IPv4, but highly desirable for modern real-time applications.
In view of these issues, the IETF established an IP next generation working group and published
RFC1752 [14].
Eventually, the specification for Internet Protocol, Version 6 (IPv6) was produced in RFC 1883. It
has since been obsolete by RFC2460 [15].
IPv6 offers the following significant features:
      A dramatically larger address space, which is said to be sufficient for at least the next 30
       years
      Globally unique and hierarchical addressing, based on prefixes rather than address
       classes, to keep routing tables small and backbone routing efficient
      A mechanism for the auto-configuration of network interfaces
      Support for encapsulation of itself and other protocols
      Class of service that distinguishes types of data
      Improved multicast routing support (in preference to broadcasting)
      Built-in authentication and encryption




                                             Page 20 of 48
                                 IST IP NOBEL "Next generation
                                                                                 Title of the document
                                 Optical network for Broadband
                                      European Leadership"                   d3b95c2d-c84f-4997-a686-
                                                                                   166859b24a5d.doc




      Transition methods to migrate from IPv4
      Compatibility methods to coexist and communicate with IPv4
If the Internet is to realize the benefits of IPv6, then a period of transition will be necessary when
new IPv6 hosts and routers deployed alongside existing IPv4 systems. The migration techniques
are collectively termed Simple Internet Transition (SIT). The transition employs the following
techniques:
       
       Dual-stack IP implementations for hosts and routers that must interoperate between IPv4
       and IPv6.
     Imbedding of IPv4 addresses in IPv6 addresses. IPv6 hosts will be assigned addresses
       that are interoperable with IPv4, and IPv4 host addresses will be mapped to IPv6.
     IPv6-over-IPv4 tunneling mechanisms for carrying IPv6 packets across IPv4 router
       networks.
IPv4/IPv6 header translation. This technique is intended for use when implementation of IPv6 is
well advanced and only a few IPv4-only systems remain.



           2.3.2 Service Stratum

                         2.3.2.1 Network Services

L1 VPNs

L1 VPNs are virtual private networks made up of leased circuits connecting customer sites.The
introduction of transparent networks will make it possible for Network Service Providers to offer
new types of services that are based on the offer of a specific wavelength connection though the
network. These new services are called wavelength services. A wavelength is an analogue signal;
there are currently no reliable means for fully managing an analogue signal, e.g. to verify
connection integrity, verify signal quality and to do fault localisation. Only way to offer a managed
service is to do access digital information (at least) at ingress and egress points by doing electrical
regeneration and framing. This wavelength service can be accordingly split in two main groups:
          A framed wavelength service where the NSP access the digital information and put client
           data in e.g. G.709 or STM frames. In this case the framing takes place on the NSP side,
           which enables the NSP to deliver a service which is fully managed. A framed wavelength
           service is not optically transparent.
          An unframed wavelength service is a service where no electrical framing is done by the
           NSP. The NSP cannot in this case verify the digital information and thus not fully manage
           the service. An unframed wavelength service can be optically transparent.
By combing a wavelength service with a control plane technology it would be possible to part of
the functionality for managing the service to the client and it is also possible to define a L1VPN
service based on wavelength services.
Framed wavelength services providing point-to-point transport of a predefined type of frame, e.g.
Ethernet or STM are well established (and will be discussed subsequently). In addition to these
already existing services, new types of wavelength services was discussed in Deliverable 21 of IP
NOBEL. An important conclusion was that lack of ability to fully manage the service is a strong
argument against unframed wavelength services. The introduction of a transparent network layer




                                             Page 21 of 48
                             IST IP NOBEL "Next generation
                                                                                Title of the document
                             Optical network for Broadband
                                  European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                 166859b24a5d.doc




is primarily for the potential benefit of the NSP, improving the cost efficiency for producing framed
VPNs on L1,L2 and L3.


L2 VPNs

       Lucent contribution

L3 VPNs

Virtual private networking, based on the usage of a shared public network infrastructure to
emulate private network facilities for a (enterprise) customer, is one of most important services
offered by a provider. A well balanced VPN service can be the basis for managed IP telephony,
hosted applications, e-commerce, integrated access or multimedia applications. The type and
deployment of the L3 VPN architectures of choice, affect the range of services which can be given
and the quality of given services.
Below is a simple scheme about the different classifications we can make in Provider Provisioned
VPNs (PPVPNs) based on RFC 4026 (only standardized solutions are shown). At this stage we
will only handle requirements and differences between major classes. Previous WP1 Nobel
deliverables [D6,D11,D21] provide more information about VPNs, while specific L3-solutions are
presented in Chapter 3.




Firstly, it is important to define in which case L2 VPNs are preferable than L3 VPN solutions. L2
VPNs are based on switched architectures, while L3 VPN ones are based on routed architectures.
As stated in [23] and [24], a L2 VPN is basically a private “WAN Ethernet”, with typical ethernet
access speeds in the range [10, 100, 1000] Mb/s. L2 VPNs may use Ethernet-switching/optical
QinQ or MPLS L2 VPN. The Service can be point-to-point or point-to-multi-point, and, most
importantly, can be network protocol neutral.
On the other hand, L3 VPNs generally provide a virtual full mesh of private routed connections
over the provider IP network, which can be accessed via Leased lines, FR, ATM, IPSec VPN, etc.;
as long as the network protocol is IP.
The aspect that stands out in the difference between L2 and L3 VPNs is that routing is provided
for you in L3VPNs. For this reason, L3 VPNs are suitable to smaller organizations or retailers, and
in general, in case of lack of routing knowledge. The automatic route discovery-feature in layer 3
VPNs can also be interesting for carriers serving large VPNs with changing/nomadic locations.
Apart from this, for ISP’s that are already familiar with technologies for L3VPNs (e.g. MPLS/BGP,
etc.), Layer 3 MPLS VPNs will likely remain the most appealing solution.




                                           Page 22 of 48
                                   IST IP NOBEL "Next generation
                                                                                           Title of the document
                                   Optical network for Broadband
                                        European Leadership"                           d3b95c2d-c84f-4997-a686-
                                                                                             166859b24a5d.doc




The economic aspects are also relevant, as L3 equipment can become quite expensive, and the
extensive growth of networks can require more and more memory for the management of routing
tables.
Another philosophy can be that for example bigger companies or organizations would like to
control their own routing policy can have benefit by choosing for L2 options. Also when
interoperability with existing Layer 2 technology is important, Layer 2 solutions can win the race.
L2 VPNs in general can also be appealing for situations where routes are likely to be static and
private networks simple, because they are simple to deploy in those cases.
At another level we can distinguish VPNs on the side where VPN processing takes place. In the
CE-based variant, all VPN specific processing takes place in the CE devices, whereas in PE-
based solutions the CE-devices are unaware of the fact of the “Virtual” aspect of the private
network. In those cases all VPN-related duties are executed between the Provider Edge routers,
as shown in the picture below.
While the tree structure only shows a CE-based solution for layer 3 VPNs, CE-based VPNs are
also possible at the second layer (see draft-lee-ce-based-vpl-02.txt).

                                                                     Customer A
                                                                       Site 2

                           Customer A                                            CE
                                   Site 1                                Community
                                      CE                PE                  RED


                           Community          PE
                              RED
                                                   P
                                                                             P


                       Customer B
                                              PE    P                    The provider
                          Site 1                             PE            network
                                     CE
                        Community                                         Customer B
                          VIOLET                                              Site 2

                                                                    CE
                                                             Community
                         Tunnel terminated                   VIOLET
                         At PE’s
                         => Provider-based VPN


                   Figure 2.8: Provider-based and Customer-based L3 VPNs


A lot of thoughts can be given in comparing both approaches (CE-based vs. PE-based) in general.
Nevertheless we will postpone these until the section in chapter 3 about CE-based IPSec
architectures is started.
Next, we want to identify the key factors/requirements for customers making them to choose for
one or the other L3VPN solution. Doing this, we use the state-of-art as from the L3VPN working
group from IETF.
We can split the requirements in the following categories (focussing on the first part), as done in
the set of RFC’s ([25] and [26]):
      Service requirements: observable/measurable attributes of the VPN for the customer. Key
       service requirements are given below.




                                               Page 23 of 48
                           IST IP NOBEL "Next generation
                                                                              Title of the document
                           Optical network for Broadband
                                European Leadership"                  d3b95c2d-c84f-4997-a686-
                                                                            166859b24a5d.doc




       a. Availability & stability
                i. Highly depends on the maturity of the solutions (being) developed.
       b. Scalability
       c. Support for arbitrary topologies
                i. Any type of mesh should be supported. A full-mesh is probably a strict
                   requirement when a lot of multi- or broadcasting applications are used on
                   top of the service.
       d. Routing policy integration
                i. It can be required that some traffic is routed via a certain path.        VPN
                   solutions should enable the configuration of this.
       e. Data isolation
                i. Between different VPNs deployed on the same infrastructure
                ii. Between data traffic and routing within VPN
               iii. Between VPN traffic and other backbone traffic
       f.   Discovery-mechanism for new sites
       g. Security considering data, access, authentication & (DoS)-attacks
                i. Protection of data, identity & resources.
       h. Support for QoS & SLAs
                i. Support for IntServ and/or DiffServ or other quality enforcement techniques.
       i.   Support for interworking scenario’s
                i. Support for scenario’s where multiple SP’s are involved.
       j.   Migration/cost effort
       k. Support for additional services, eg. Internet access & VPN access within site
   Provider requirements: mainly scalability and management characteristics for service
    providers considering different VPN technologies.
   Engineering requirements, which are implementation characteristics which make service
    and provider requirements achievable, such as:
       a. Separation of the VPN solution and eg. tunnel type used
       b. Mechanisms for incorporating existing protocols in VPN solutions




                                       Page 24 of 48
                                         IST IP NOBEL "Next generation
                                                                                                                 Title of the document
                                         Optical network for Broadband
                                              European Leadership"                                           d3b95c2d-c84f-4997-a686-
                                                                                                                   166859b24a5d.doc




Business/Public IP

The majority of traffic generated by end-users’ applications is natively IP; since the beginning of
Nobel project [D6], WP1 has considered 3 different kinds of L3 services: Public IP, Business IP
and L3VPNs, addressing toward increasing level of quality. In more details Public IP is considered
as best effort service, Business IP as an IP service with some quality requirements and, of course,
with some defined SLA between the customer and the service provider.
At this point it is very important to consider that the IP networks does not carry only IP native
traffic, but also some other kind of traffic, voice in particular, that is not packet native, but it is
packetized and than transported over an IP infrastructure. From one side it give some advantages
to the network provider ever since often packet connections (IP) are less expensive than circuit
ones and the versatility of IP network allows the possibility of sharing transmission resources
among a set of applications.
So the end point of an IP network may be both the final user application and a point of traffic
concentration. From Nobel point of view, ever since the access section is not considered, the
distinction between end users customer (of the IP network) and concentrator of traffic is not very
important, but this is a signal that L3 traffic covers an important section of the total amount of
traffic over the network.

                                 ACCESS                      METRO/REGIONAL                 BACKBONE

                                                                         PoP IP
                                                                        RNC        L2/L3
                                                                                   switch   IP/MPLS Backbone
                                                  SL
                                                        Concentration
                                                           network
                                                         (SDH, GBE,
                                 NodeB      IP DSLAM        WDM)
                                                                               Storage
                                                                        GGSN-BRAS-              Terarouter
                                                                        PE
                                HOME/SOHO    SL




                                            DSLAM ATM

                     BUSINESS


                                                                        Peer client
                                                                        IP network




                                                                           Nobel perspective


                                Figure 2.9: IP network as convergent network
The Figure 2.9 show a case, very useful adopted by incumbent network operators where a
plethora of services/applications are carried over a packet (IP) network.

                        2.3.2.2 User services: Fixed-mobile Convergence
The convergence of fixed and mobile user services is expected to be one of the issues of major
concern for operators in the short and medium term. In this section, we will describe the current
situation of the available technologies for Fixed and Mobile Convergence (FMC). Furthermore, we
will also include a brief description of some results derived from MUSE project related to potential
scalability problems of current standardization approaches.




                                                               Page 25 of 48
                             IST IP NOBEL "Next generation
                                                                                Title of the document
                             Optical network for Broadband
                                  European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                 166859b24a5d.doc




Motivation and key issues for Fixed and Mobile Convergence
Fixed and Mobile Convergence covers both infrastructure and services. On the one hand FMC
deals with the capability of a unique network to support fixed or mobile applications. On the other
hand FMC is also related to those convergent services that can be offered to users (residential or
professional subscribers) through a common infrastructure.
In this respect, there exists a widespread agreement about that fixed and mobile services will
converge on a common IP infrastructure. However, there exist two divergent viewpoints about how
these common IP networks should be built:

                              Table 2.7: Models for FMC networks
                           PSTN-like                    Internet-like
                       Application-aware            Application-unaware
                      QoS definitions and        QoS per aggregated flows
                      guarantees per flow


Under an operator point of view there are two main drivers for an evolution towards common IP
networks fro fixed and mobile services:
    Cost reductions (OPEX&CAPEX) by implementing common core infrastructure and service
     platforms for different access networks: Any combination of mobile and fixed voice, video
     and data services decrease operational costs by using common resources, transport,
     operation and maintenance, etc
    FMC leads to a new market with unique list of services and high revenue potential. So,
     revenues may increase due to an easier and quicker provision of new convergent services
     (e.g Fixed&Mobile VoD).
However, operators are aiming to evolve to this common IP backbone without losing important
capabilities (e.g VoIP infrastructure should preserve as many PSTN attributes as possible). So,
operators are supporting the “PSTN-like” model where the convergent IP network, which is called
Next Generation network (NGN), can provide specific QoS for a particular application, such as
VoIP, VoD, videoconference, etc. To facilitate the migration towards this model, many carriers
started participating in a major international standards development effort.


Main Standardization approaches for FMC: IMS&TISPAN
The ITU defines NGN as: "A packet-based network able to provide telecommunication services
and able to make use of multiple broadband, QoS-enabled transport technologies and in which
service-related functions are independent from underlying transport-related technologies. It
enables unfettered access for users to networks and to competing service providers and/or
services of their choice. It supports generalized mobility which will allow consistent and ubiquitous
provision of services to users" [7].
Architecturally, the NGNs rely heavily on the IP Multimedia Subsystem (IMS) framework, originally
developed by the 3GPP (3rd Generation Partnership Project)/3GPP2 for 3G/UMTS and CDMA
mobile/cellular networks. IMS creates a signaling network for NGNs that acts as a
wireless/wireline control plane. So, it allows offering network controlled multimedia services in



                                            Page 26 of 48
                                    IST IP NOBEL "Next generation
                                                                                                                                        Title of the document
                                    Optical network for Broadband
                                         European Leadership"                                                                    d3b95c2d-c84f-4997-a686-
                                                                                                                                       166859b24a5d.doc




NGNs. As shown in the following picture IMS framework is based on technologies and protocols
developed by the IETF (SIP, Diameter, CPOS, ENUM):




                             Figure 2.10: FMC based on IMS configuration


TISPAN is the ETSI proposal for a NGN architecture. It is based on the 3GPP-IMS specifications,
extending them for their implementation in any kind of network. The TISPAN architecture shown in
the next figure is based upon the concept of cooperating subsystems sharing common
components. It is designed to enable the addition of new subsystems over the time to cover new
demands and service classes.


                     It includes IMS in the NGN architecture



                                                              Applications


                                                                       PSTN / ISDN emulation
                                           User                       Multimedia Components
                                           Profile                   (Core IMS, Streaming, etc.)
                                                                                                               Other Networks
                                                                                                   PSTN /
                                                                                                   PSTN /
                                                                                                   PSTN /
                                                                                                    ISDN




                                     Network Attachment                     Resource and
                                                                                                                                NOBEL
                                        Functionality                      Admission Control                                    Scope
                                           NASS                                 RACS


                                                                                     TGW
                                           Access       IP
                                         Access
                                          Transport                                   Core
                       CPN                             Edge
                                                       IP         Edge                                Edge
                                        Transport
                                           Network                                  Transport
                                                       Node
                                                      Edge        Router                              Router
                                         Network                                     Network
                                                      Node


                                          3GPP         IP
                                         IP-CAN       Edge
                                                      Node
                   3GPP Terminals                                                        IP-CAN      Connectivity Access Network
                                                                                         TGW         Telephony Gateway




                                    Figure 2.11: ETSI/TISPAN Architecture


QoS control in IMS&TISPAN




                                                              Page 27 of 48
                             IST IP NOBEL "Next generation
                                                                                                        Title of the document
                             Optical network for Broadband
                                  European Leadership"                                              d3b95c2d-c84f-4997-a686-
                                                                                                          166859b24a5d.doc




Nowadays the IMS model is being acclaimed as a potential solution for QoS. The principles on
which the QoS control architecture of the IMS model is based are as follows:
    A central view is kept of all network resources in the access network
    A central view is kept of all resources that are currently in use
    Requests for network resources are accepted or denied individually and on request.
     Requests are only accepted if the network resources available at the time of the request
     are sufficient to meet the requested QoS
    Requests for network resources can be made by end users and by application service
     providers
    Resources are reserved after a request has been accepted and released after the session
     has finished
    Requests, acceptance and reservation of network resources can be handled independently
     for the upstream and downstream directions. For example, the upstream and downstream
     directions can have different delays and packet loss
On the other hand, TISPAN is based on the 3GPP-IMS specifications and the QoS control for
each connection is also assured by a centralized element called Resource Admission Control
Subsystem (RACS).


                                                                                AF


                                                                       Gq’
                               NA SS            RACS                                            NOBEL
                                           e4
                                                                  Rq         S PDF              Scope
                                                 A- RACF

                                                 Re                        Ia

                                Ra


                                                  RCE F                         BG F

                                                  L2 T
                                Ac c ess          Po in t                                  Ds
                      C PE                                      Di
                                N ode                                      Cor e
                                                 Ip Edg e                  Border N od e

                                                      Tra nsp ort La yer




                Figure 2.12: Resource and Admission Control in TISPAN R1
According to the specifications of TISPAN R1 the principles on which the QoS control is based are
as follows:
    A centralised functional entity (called SPDF) decides the appropriate policy for a given
     requested service (policy push model).
    A packet to packet gateway for user plane media traffic (called C-BGF) performs policy
     enforcement functions under the control of the SPDF.
    The RCEF performs policy enforcement functions making use of policies defined by the
     access provider.
    The Access Node is supposed to be a L2 equipment




                                                Page 28 of 48
                                                             IST IP NOBEL "Next generation
                                                                                                                                         Title of the document
                                                             Optical network for Broadband
                                                                  European Leadership"                                            d3b95c2d-c84f-4997-a686-
                                                                                                                                        166859b24a5d.doc




2.4                  Topology: Constraints and requirements

                     2.4.1 Metro/regional network
     At present, the first step of traffic aggregation is mostly achieved by SDH rings at present with
     the city shape. This is the metro-access level or first aggregation level but big cities, like
     Madrid, aggregate traffic again within a second SDH ring in an upper aggregation level: The
     metro-core level (Figure 2.13.a). Another current architecture, developed on the basis of
     Ethernet technology, is presented in Figure 2.13.b: Clusters of routers (and DSLAMs) linked
     to GbE switches that, in turn, are part of a mesh.
                                                                                                       VoD Servers
                                              Stacks of SDH Metro                                      TV Head End         Backbone/Internet
                                                 Backbone rings                                                      Metro Core

Access Node           Metro Backbone
              ADM

                 .
                           Node                                      ADM

                                                                       .                                                                       Hubs Metro Core
                 .                                                     .
              ADM.                                                     .
                                                                     ADM

                       ADM           ADM       ADM          ADM
     ADM
     ADM

                       ..            ..         ..           ..            ADM
                                                                           ADM




     ADM
     ADM
        .
        .
        .              .             .          .            .             ADM
                                                                           ADM
                                                                              .
                                                                              .
                                                                              .          Leased line                                           GbE & 10 GbE
                       ADM           ADM       ADM          ADM
              ADM            DXC                     DXC             ADM                                                                         PtoP links
                 .                                                     .
                 .                                                     .
              ADM.                                                     .
                                                                     ADM




              ADM
                                                                     ADM            Local                                                      Access Nodes
                                                                       .
                 .
                 .     ADM           ADM
                                               ADM         ADM         .
                                                                       .            PSTN
              ADM.
                        ..            ..        ..          ..       ADM




     ADM
     ADM

                        .             .         .           .
                                                                           ADM
                                                                           ADM

                                                                              .
                                                                                  Exchange
        .                                      ADM         ADM                .
        .              ADM
                       ADM           ADM
                                     ADM
     ADM
     ADM.
                                                     DXC                   ADM
                                                                           ADM.
                             DXC
                                                                     ADM
              ADM
                                                                       .
                 .                                                     .
                 .                                                     .
                                                                     ADM
              ADM.
                                   Stacks of SDH Metro
                                       Access rings


                               (a)                                                                                        (b)

Figure 2.13: Present metro network architectures: (a) Two levels SDH rings and (b) Ethernet
                       stars linked through a mesh of GbE switches

     Introduction of IP is a paradigm that leads to transform metro network architectures: Migration
     of almost all services to (packet oriented) IP, and adaptation of the (low cost) Ethernet
     technology to them. Such a task can be achieved by different technologies, as analysed in
     Chapter 3. But there is a general consensus about the advantages of transforming the upper
     level of aggregation into a mesh (Figure 2.14) not only for the possibility of implementing more
     efficient (cost-effective) resilient mechanisms as IP capacities go to the optical layer but also
     for the benefits of it under a distributed control plane (upon the basis of GMPLS governed
     devices): Fast traffic engineering allow carriers to optimise network resources (transferring
     traffic in/from business areas in the morning to residential areas in the evening, for instance).




                     CORE & METRO-                                                                                       SECOND LEVEL OF
                     CORE NETWORK                                                                                          AGGREGATION
                                                                 1 nod
                                                                   es



                                                                                                            FIRST LEVEL OF
                                                           Metro access nodes                                AGGREGATION




                                                                                  Page 29 of 48
                            IST IP NOBEL "Next generation
                                                                            Title of the document
                            Optical network for Broadband
                                 European Leadership"                  d3b95c2d-c84f-4997-a686-
                                                                             166859b24a5d.doc




          Figure 2.14: Metro network with a mesh as second level of aggregation




         2.4.2 Core/backbone network
Figure 2.15 depicts a situation where routers are connected among them via physical links. The
transmission layer is very easy because it consists of a set of point-to-point connections (e.g.
lambdas in WDM systems). Resilience is provided only at IP (or MPLS) level and, to fast the
revelation of failures, often expensive PoS (packet over Sonet/SDH) ports are used. The logical
topology of the IP network is identical to the physical one, so that no high mesh degree are
possible. For this reason, to minimize the number of node pass-through, a hubbed topology is
usually adopted. In the hub nodes, a large-size router (e.g. a teraRouter) is often necessary.




    Figure 2.15: the routers are connected by point to point physical connections. The
    switching is provided only at IP layer, no grooming between IP and circuit traffic is
                    possible. The resilience is possible only at IP layer.




                                         Page 30 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                      d3b95c2d-c84f-4997-a686-
                                                                                   166859b24a5d.doc




Figure 2.16: the OTN receive the traffic from the IP network (i.e. from routers) and their role
  is only to groom IP traffic with circuit native, but the switching is provided at IP layer. A
       second role of the OTN is to provide a more cost-effective and fast restoration




Figure 2.16 depicts an intermediate network design, where a transmission network exists and
collects the traffic generated by IP networks coming from routers; the logical topology is identical
than in the previous case and, for this reason, the switching of IP traffic is provided by routers. The
advantage of this solution is twofold:
      The possibility of groom packet and native circuit traffic, so to save bandwidth
      The possibility to implement resilience at circuit level for failure interesting the physical
       layer (e.g. fibre cuts) that is faster and more efficient.
The cons might be the cost of this solution. It is necessary to valuate if the bandwidth saving due
to grooming between packet and circuit traffic and the possibility to connect routers and O(D)XCs
with GbE interfaces, cheaper than PoS adopted in the previous solution can balance the cost of
the installation of the transmission devices.




Figure 2.17: the switching is provided at transmission layer: the routers are connected by a
  fully-meshed topology and the switching is provided by the optical network. Grooming
 between IP and optical-native traffic is of course possible. All the techniques of multilayer
                                   resilience are possible.


Figure 2.17 depicts a solution where the “intelligence” and the switching capabilities are moved
toward the transmission level. The logical topology of this solution is usually (quite) full-meshed,
such as the routers see the others with a single hop.
The advantages of this techniques is the possibility of groom bandwidth between circuit and
packet traffic and this solution allows multilayer resilience techniques with a further bandwidth
saving and the possibility to implement classes of resilience.
This solution may be not too expensive, due on the minor cost of L1 internal node transit than L3,
but it depends on traffic pattern and on the interface granularity.



                                            Page 31 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




This problem will be deepen in the next section.


2.5       Specific applications
In this Section, we investigate requirements from a new group of applications, including
Computing Grids, Consumer and Media Grids, Storage and Video on Demand.


2.5.1          Computing Grids
The purpose of this section is to concentrate on some computing Grids use cases. Background
information on the Grid architecture, resource virtualization and network infrastructures for Grids
can be found in Appendix.
Resource-sharing is one of the Grid intrinsic properties enabling efficient usage of services by
clients from many Virtual Organizations (VO). This is particularly true for network infrastructures.
In such an intensive networking environment, the support of network Quality of Service requires
the establishment of Service Level Agreements between users and network service providers.
Another required functionality is authentication, authorization, and admission control as well as
automated service provisioning and Traffic Engineering provided by the control plane. The
availability of service guarantees allows flexible usage of the distributed infrastructure and enables
considering end user application-controllable performance criteria.
As the user application requirements are quite diverse, a computing Grid is designed to serve a
potentially infinite number of different applications. The Global Grid Forum has identified a non-
comprehensive list of both scientific and business use cases that are divided in two groups: path-
oriented and knowledge-based. “The former group includes use cases with various specific
connectivity service level requirements, while the latter includes information-oriented use cases
related to network monitoring and usage scenarios of performance data” [45].
We restrict our scope to path-oriented use cases. In this document we select three specific cases
for different types of VPN technology, namely: data distribution, data replication, and data
streaming coordinated with job execution.


2.5.1.1    Data Movement
Different architectural approaches to data movement can be chosen in Grids. In this document we
consider the one adopted in Europe and defined in the framework of the EGEE project [37]. Most
“Data movement services provide scalable and robust managed data transfer between Grid sites,
to and from Grid storage. Files are scheduled to be moved between sites reliably. The services
involved in data movement are the following, as shown in [37].

   Data Scheduler: From the VO’s point of view the Data Scheduler is a single central service. It
    may actually be distributed and there may be several of them, but that depends on the
    implementation. It accepts high-level transfer requests, where the user does not specify the
    source replica, or even the destination of any given transfer.

   File Transfer/Placement Service: The transfer and placement services may get transfer
    requests from the user directly or through the Data Scheduler. The difference between a
    transfer and placement service is only their connection to the catalog, i.e. the service that
    maps a Logical File Name (LFN) to the corresponding physical location Site URL (SURL) and
    Transport URL (TURL). The transfer service does not provide LFN and file Grid Unique



                                           Page 32 of 48
                              IST IP NOBEL "Next generation
                                                                                  Title of the document
                              Optical network for Broadband
                                   European Leadership"                      d3b95c2d-c84f-4997-a686-
                                                                                   166859b24a5d.doc




    Identifier resolution into SURL/TURLs. The deployment of FTS and FPS services depends on
    what the needs of the VO are. It is possible to have a service at each site.

   Transfer Queue The transfer queue is persistent and is not tied to a site, but rather to a set of
    connections, wide area network channels (links). It keeps track of all ongoing transfers and
    may also be used to keep a transfer history, for logging and accounting purposes.

   Transfer Agent The transfer agent again is tied to both the network channels and the VOs (see
    details below). The Agent may not only simply get the next transfer job out of the queue, but
    may also reorder the queue according to site and VO policies.”




 Figure 2.18: Architecture overview of the Data Movement service components. The Data
Scheduler is a high-level component. There may be many File Placement Services around,
            acting as interfaces to put requests into the Transfer Queues [37]


       Transfer Channel: The Data Movement services need to interoperate and manage two
        basic resources: Storage and networking. For the network side, we use the concept of
        Transfer Channel, which is a network path, i.e. a resource virtualization. Each File Transfer
        Service can control several channels. In particular, a file transfer request can be satisfied
        only if the source and destination SEs involved in the transfer are connected by a Transfer
        Channel. GridFTP, an extension of the standard ftp protocol, is used to exchange data
        between the two end-points of the transfer channel.


Case 1: LHC Computing and Electronic Very Long baseline Interferometry
In case of File Transfer Services handling channels according to a start topology (i.e. where many
channel have an end-point in common), network bottlenecks may arise, especially if the transfer
channels are requested to support high-throughput transfer in a sustained fashion. This is the data
access pattern in use in several application domains.
       For LHC Grid Computing 1.6 GB/s data recording from disk servers at CERN to tape
        devices at Tier-1 sites distributed worldwide will be required. In particular, every Tier-1 site
        will be connected by at least one transfer channel to/from CERN, where the guaranteed
        bandwidth requested per-channel is 10 Gb/s.




                                            Page 33 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




      Similar bandwidth requirements arise in the Electronic-Very Long Baseline Interferometry
       (E-VLBI) experimental environment [46], where data are gathered from a large number of
       peripheral notes to a single, central computing site, where data are finally correlated and
       processed.
      The high-speed connections required in this scenario are typically associated to transfer
       channels, and meant to support high volumes of sustained traffic for a long time span
       (several months or years), and hence can tolerate a manual or quasi-manual configuration.
      High availability is required. Typically 24 hour/day, 7 days/week availability is demanded.
Case 2: Visualization
As detailed in [45], “visualization is one of the key methods used to represent data (raw or
processed) and is used extensively by almost all fields of specialization for instance e-sciences,
medicine, engineering and digital art. A visualization session may either use data-sets available
either locally or remotely. Remote visualization, tele-immersion, collaborative visualization, tele-
operation, and distributed simulation analysis are examples of applications requiring a significant
amount of Grid resources (network resources included). Also, parallelizing techniques have
proved promising in three areas: 1) server-side functions, 2) client side functions, 3) object
rendering. The specific requirements include:
 With regards to the latter area, rendering and display have stringent bandwidth, latency, and
    jitter requirements, especially when remote. Applications requiring visualization analysis of
    very large data sets on the order of terabytes to petabytes from remote locations.
 For extremely large data sets, the data could be divided over multiple servers for more efficient
    computation and I/O, which allows the establishment of multiple parallel data transfer
    sessions.
 A single object rendering display is associated with a separate remote server for its server side
    numerically intensive computations. User input at the client (e.g., “change this isosurface
    level”, “rotate display”, “analyze variable X”, “animate over time or space”) generates control
    commands that are passed to the remote servers. Each update is latency and jitter sensitive.
    As the user rotates the object via mouse movement, near-real-time object rendering occurs. It
    has been shown that in tightly coupled networked manipulation tasks involving distantly
    located collaborating partners, 200ms round trip latency is the maximum acceptable latency.
 For rendering on a large rendering servers (such as the TeraGrid visualization cluster) and
    the pixels multicasted to the remote viewers. In these scenarios a 1000x1000 pixel 30 frames-
    per-second animation sequence requires a throughput of approximately 680Mb/s. However,
    streaming graphics to fill a 100 megapixel display will require between 6.8Gb/s and 68Gb/s.”
 High availability is required. Typically 24 hour/day, 7 days/week availability is demanded.

2.5.1.2   Data Replication
Data replication is data management strategy which consists in generating multiple copies of data
in order to increase the data access performance in different ways:
1. Replication guarantees high data availability. For instance, in case of SE failure, the local copy
   of a given file can be restored by locally copying one of the file instances available in the Grid.
2. The availability of multiple consistent replicas supports application-layer load balancing, as the
   traffic produced by executables running on different CE locations and accessing the same files
   can be distributed to different network paths, as identical file instances are geographically
   distributed.




                                           Page 34 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




3. Replication can also enhance the performance experienced by GridFTP sessions. In fact,
   GridFTP can be executed in striped mode, i.e. different portions of a given file can be retrieved
   from different sources, i.e. from distributed replicas. The consequence is that, if GridFTP in
   striped mode is used, the per-session aggregate throughput is typically the sum of the
   throughput experienced by each individual data connection established to retrieve one file
   portion. This performance gain is particularly important for data transfer sessions on high-
   speed long-haul connections for a more efficient utilization of the bandwidth available.
Data replication can be supported at the cost of higher storage space availability, of consistency
management of different file replicas, and of maintenance of Grid catalogs mapping logical file
names to physical file names (one physical file name for each replica available).
Replication can be performed according to either a pull or push scheduling approach. The pull
approach allows remote SEs to individually trigger the GridFTP session for the generation of a
new data set replica according to their local policies and status (such as the availability of
sufficient storage space). Conversely, the push approach requires the SE holding the master copy
to initiate the various transfers. In such as way, a more coordinated replication approach is
possible.
Replication is typically used in case of application requiring high availability of critical data. For
instance, the Distributed Aircraft Maintenance Environment described in [45] “provides a Grid-
based, collaborative and interactive workbench of remote services and tools for use by human
experts. It currently supports remote analysis of vibration and performance data by various
geographically dispersed users: local engineers and remote experts.
The diagnosis environment is built around a workflow system, and an extensive set of data
analysis tools and services, which can provide automated diagnosis for known conditions.” In this
application scenario, when an aircraft lands data from on-wing system is automatically
downloaded to the associated local Ground Support System, which indicates whether any
abnormality (this is a detected condition for which there is a known cause) or novelty (this is a
detected deviation from normality for which there is currently no known cause) has been
detected.” In this case, Grid data management and movement need to support:
 appropriate access by users to the terabytes of historical data from the engine under
   consideration and other similar engines;
 a diagnostic process to be completed in a timely and dependable manner commensurate with
   the turn round times of the aircraft;
 data integrity and confidentiality.


2.5.1.3   Data streaming coordinated with job execution
As described in [45], the coordinated use of multiple resources is particularly challenging in Grid
infrastructures, due to the distributed nature of the resources involved in complex workflows with
internal dependencies. A Grid network service, guaranteeing the timely access to remote
resources, allows the synchronization of the individual components of a complex workflow, with a
consequent gain in terms of resource usage efficiency.
In the specific case of data access, high-throughput file transport with deadline allows the
synchronization of job execution with the transfer of input data. For example, input data can be
pre-staged while in the meantime the corresponding job is waiting for being executed. The
coordination of data streaming and job execution can be effectively used by any Grid application
that is oriented to the processing of large volumes of data, such as in LHC computing.
Job and file transfer synchronization are characterized by the following aspects.



                                           Page 35 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                      d3b95c2d-c84f-4997-a686-
                                                                                   166859b24a5d.doc




    Clients require the possibility to dynamically request a given amount of guaranteed
     bandwidth between well-defined network end-points.
    The amount of bandwidth requested time by time may be very variable, depending on the job
     execution requirements.
    For the reason mentioned above, network capacity should be guaranteed on short time
     scales (maximum tolerance: 2-3 min, depending on the duration of the job execution), as
     every job may feature completely different requirements from a quantitative perspective.
    Data confidentiality and integrity may be requested depending on the job.



2.5.2          Requirements for consumer and media Grids
Grid networks
<Tiziana: the following three paragraphs are more about computing and storage requirements
rather than about network requirements, maybe the title can be change accordingly?>
During the past decennia, computing resources such as processor power and storage capacity, as
well as network speeds have known a remarkable increase. Despite this evolution, there are
applications where deployment of dedicated hardware is not a profitable approach. For these
applications, the Grid concept offers a solution: resources can be combined and shared between
several clients, thereby reducing the per-client infrastructure cost. This flexibility is achieved by
using an underlying network to transfer jobs from client to resource.
First generation Grid networks comprise mostly eScience applications: particle- and astrophysics
and biomedical research are typical examples. In these Grids, the number of users is relatively
low, but the computational and storage demands are enormous. An evolution exists however
towards service-oriented Grids with a larger amount of users and more diverse types of tasks,
exhibiting an increased (and near real-time) interactivity with the users, as opposed to the
traditional Grid solutions. Resources will become more scattered as infrastructures from different
locations become interconnected. Combined with the need for more interactivity, this will have a
severe impact on the network requirements.
Figure 2.19 shows an overview of the different Grid types and their respective job requirements.
As can be seen on the figure, the group of service Grids can be divided into two subcategories,
one for residential users and one for enterprise customers.
<Tiziana: can you clarify the unit for the y axis?> <Bela: It would be nice to see the intensity in the
network usage. If not we can say that the impact on the network is ignored.>
The figure provides an indicative overview of required processing power (light gray bar, typical unit
would be GFlops), storage requirements (dark gray bar, GByte) and the typical number of users
(dashed horizontal line) for each given grid type.




                                            Page 36 of 48
                                    IST IP NOBEL "Next generation
                                                                                              Title of the document
                                    Optical network for Broadband
                                         European Leadership"                          d3b95c2d-c84f-4997-a686-
                                                                                             166859b24a5d.doc




                typical job size   cpu
                                   data
                                              eScience grids                  service grids
                       # users
                                                                      business          residential




                                                                grid type

 Figure 2.19: Qualitative comparison between requirements of different Grid environments
<Bela: The problem here (Table below) is that in case the CPUs are in a LAN we do not tackle the
issue in NOBEL. So somehow the Table is not explanative.>


      Project           CPU power               Storage capacity            Link capacity
      EGEE              10.000 CPU’s            10 PByte                    <= 10 Gb/s (GEANT)
      TeraGrid          40 TFlop                2 PByte                     10 Gb/s
      BlueGene/L        136 TFlop               N/A                         N/A

                                    Table 2.8: Current eScience projects

Consumer Grids
<Bela: Is this in the scope of NOBEL? My impression is that we never leave a residential network.
It could be a good example for NOBEL in case the Consumer Grid requires Internet. In other
cases, the target is missed.>
Residential Grids or consumer Grids will need to administer services to a large amount of home
users. The resources for these home users however, need not be located within the residential
network they reside in. Depending on the required application, use of the grid might even require
(paying) access to dedicated resources provided by “grid service providers”.
A typical use case for these Grids is the online visualization of a virtual environment (gaming,
virtual reality). A virtual environment is typically made up of various objects, described by their
shape, size, location, applied texture, etc. Usually, the description of a scene can be realized in a
limited storage space, typically around a few MB. Rendering the scene however, requires
substantial computational power: a demand of 300 million polygons per second results in required
capacities as large as 10.000 GFlops. With a frame rate of 25 fps, latency below 40 ms per frame
is required. Assuming a 2.5 MB scene description size (transmission time of 8 ms on a 2.5 Gb/s
link), about 30 ms is the time span available for processing a frame on the remote resource, which
is feasible.




                                                Page 37 of 48
                                           IST IP NOBEL "Next generation
                                                                                                     Title of the document
                                           Optical network for Broadband
                                                European Leadership"                          d3b95c2d-c84f-4997-a686-
                                                                                                    166859b24a5d.doc




                                                             Optical Burst Switched Network




                  Fiber To The Home (FTTH)                                                     Computational
                 Passive Optical Network (PON)                                                   resource




                                                       OBS Router                                 Storage
                                                                                                 resource




          Figure 2.20: Optical burst switching for Grid applications: consumer Grid




<Tiziana: can you explain the figure above?>
<Bela: 1) What is this network, a building network? 2) We are mixing here job and size of data! 3)
Bursty nature would be OK. The call type may be not.>
Figure 2.20 shows part of the network required for the service grids: on the left side, residential
users (in their own dedicated networks) are requesting job execution. These jobs are sent into the
core network and find their way to the required resources. If the customer’s internet service
provider is also a grid service provider, then obviously, resources will be available at the first hop
in the network.
Jobs generated by clients in a consumer Grid are typically small (range of a few MB) and do not
require enormous processing power. Job generation will have a bursty nature, both in the time
when and in the location where jobs are generated. Several types of applications will require real-
time interaction, and thus strict deadlines must be met. Other applications have different degrees
of tolerance for the various system parameters, which implies the existence of several QoS
classes.
General requirements for consumer Grids can be summarized as follows:
    Scalability is an important issue, as a large number of users, jobs and resources must be
     supported. This becomes even more relevant when considering the bursty/dynamic nature
     of job transmission: peaks in the generated load should be handled seamlessly.
    It is economically not justifiable to build a dedicated network for each application.
     Consequently, the basic infrastructure should be able to support all application types, each
     with its own access and resource usage patterns.
    Support for real-time applications is only possible through adequate levels of speed and
     flexibility in the control plane, implying low latency signaling is required. Also, the overhead
     imposed by the control plane on the involved entities should be minimized.




                                                       Page 38 of 48
                                              IST IP NOBEL "Next generation
                                                                                                                                                                                          Title of the document
                                              Optical network for Broadband
                                                   European Leadership"                                                                                                               d3b95c2d-c84f-4997-a686-
                                                                                                                                                                                            166859b24a5d.doc




Media Grids
Grids for the enterprise market fill the void between the extremes posed by traditional eScience
Grids and consumer Grids.
<Bela: OK I see. Please consider my previous remark.>
In terms of number of users, average job size, bandwidth and processing requirements, these
Grids exhibit widely differing characteristics. It is this variety in requirements that leads to the need
to define this Grid type: neither traditional Grids nor consumer Grids have been designed to
manage the handling of this large diversity of jobs in an efficient manner.
One specific case of such a service Grid for the enterprise is considered: the media Grid. As the
name suggests, the primary application of such a Grid network is transferring and processing
media (audio and video) streams, in a production environment, such as a news broadcaster or
television program supplier.
As an example, consider a national news broadcaster, employing 500 journalists and 50 editors.
The editors are performing cpu-intensive operations such as fading and transcoding on several
HTDV streams of 50 Mb/s each. Journalists are either browsing the archive (at low or high
resolution) or bringing in new video material. This leads to several hundreds of different data
streams, each with its specific bandwidth (ranging from 1 Mb/s for low resolution video up to
several Gb/s for raw data) and processing requirements.

                                                                                                                         tv broadcaster



                                                                  Site 1
                                                                                                                Site 2
                                                                           tv program supplier




                                                                                                                                                                     Site 2a
                                         Site 5

                                                                                                                                                                     tv post-production
                        tv broadcaster                                                       WAN

                                                                                                                                          Site 2b


                                              Site 4                                                                                            tv post-production




                                                  tv production
                                                                                                   Site 3


                                                                                                            tv production




                     Figure 2.21: Next-generation service Grids: media Grid


Generalized requirements for media Grids, which can easily be projected on the needs envisaged
for other enterprise Grids, can be summarized as follows:
<Bela: What is ‘Grid’ in this? Elaborate on please.>
<Tiziana: would it be possible to provide quantitative estimations of the general requirements
specified below?>
    The Grid needs to be able to handle a broad spectrum of tasks, as well in storage size and
     bandwidth requirements, as in processing power.
    More than traditional Grids, media Grids should be able to handle peak loads: important
     news events draw a lot of attention and result in an avalanche of job requests to a specific
     location, requiring media files related to this event. Data replication and load balancing
     strategies for handling these peak loads are required to ensure adequate functionality at all
     times.




                                                                                    Page 39 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




     As is the case in consumer Grids, the large number of users leads to the need for
         scalability. For example, the link and resource state information in larger networks cannot
         be flooded over the entire network, so localized scheduling and routing decisions might
         need to be made by the switches.
     The media Grid will require the presence of QoS-classes, to be able to guarantee real-time
         interaction and/or ensure better, more reliable service between clients and resources for
         applications that need this feature.
     Reliability is an extremely important characteristic of media Grids. Tasks such as
         broadcasting can never be allowed to be compromised by (single and multiple) link or node
         failures.
     Security and admission control is an obvious requirement when interconnecting several
         corporate sites.
Ongoing research on media grid requirements has shown that companies dealing with media
typically match one of a number of profiles. Ranging from regional and national TV-production
sites, over post-production sites and radio and TV broadcasters, each company typically involves
a number of media grid users.
Larger national TV-production sites have as much as a few thousand journalists and several
hundred craft editors, directors and producers. Journalists are typically responsible for providing
new material. Currently these streams of raw video data are re-encoded to 50Mbps HDTV or
250Mbps SDI streams, but towards the future higher quality is likely to be required. Craft editors
are responsible for merging and transcoding several of these streams into video reports.
On a local base, this means that large amounts of data have to be processed and transported in
the local network. Currently the media sites do not employ grid strategies to accomplish this and
are therefore facing problems, as either equipment needs to be shared by having the journalists
travel from one location to another (e.g. journalists in Scotland need to process their data in the
BBC studio’s in London), or need to have a relatively large amount of surplus processing plants.
On a more global base, the local media grids can further be interconnected in order to allow
further sharing of resources, thereby reducing overall costs. This will for example allow peak loads
in smaller companies without sufficient equipment to be handled by excess capacity of larger
media sites, without inducing problems for either party.



2.5.3          Storage Area Networks
Previous studies led in NOBEL project ([2]), show traffic figures associated to storage applications.
The main results of this research are related to the amount of traffic generated by storage
applications and that said applications, grouped inside the set of storage are very different among
them.
The amount of traffic generated by storage applications is enough large, in particular in the biggest
metro/regional networks, but it does not represent one of the most important application (from the
point of view of the amount of traffic); moreover the growth of the traffic is not exponential as
occurs for other kinds of applications, but the forecast figures show that traffic will double from
2005 to 2008, while applications like VoD will probably duplicate their traffic. This fact is due
substantially on two main reasons:
       Network based storage applications have nowadays achieved a degree of maturity higher
        than VoD or TV-broadcasting, so that explosion of this services occurred some years ago;
       The technology is real expensive, both for storage hardware (tapes, disks, data-
        machines,…) and for connections. More in particular it is important to notice that the rate of
        decreasing of prices (and costs for companies) of devices is quicker than for connections.



                                           Page 40 of 48
                             IST IP NOBEL "Next generation
                                                                                Title of the document
                             Optical network for Broadband
                                  European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                 166859b24a5d.doc




On the other hand it is possible to verify that the storage applications listed and described in D21
are real heterogonous from the point of view of the required bandwidth, the modalities of using the
network and for the requirements in terms of latency, jitter and other QoS parameters.

                      2.5.3.1 Classification of storage applications
Following the requested QoS parameters, it is possible to classify storage applications into three
main categories:
      Tape
      Disk 1
      Disk 2


Tape
Typical tape storage services are: remote vaulting, remote back-up (and restore). Independently
from the bandwidth, these applications does not require short latency or low jitter. Moreover, it is
possible to schedule this services, so that it is possible to plan connections.
In general the traffic generated by tape services is constant during the period of transfer, that can
last from some minutes to some hours, depending on the bit-rate (generally limited by the rate or
the cache dimension of the data machine that acquire data) and on the amount of data set.

Disk 1
Typical applications comprising in Disk 1 class are asynchronous mirroring and distributed storage
(or SAN). These services have a requirement about QoS parameters but these requirements are
not really strong, (e.g. hundreds of ms of latency and a packet loss below 0.5%). It is not possible
usually to schedule the data transfers, but they often consist of several transactions that it is
possible to queue.
Usually the traffic profile generated by this kind of applications consists of a variable bit-rate
shape, where the bit-rate depends on the total congestion of the network or the customer or data
centre interface. In general, asynchronous mirroring use the bandwidth kept free by applications
with higher priority.

Disk 2
The Disk 2 class comprehends the storage applications requiring the highest level of QoS.
Synchronous mirroring and Storage on demand belongs at this category. This applications usually
require very strong requirements in terms of latency and, of course, it is not possible to schedule
or queue the transactions. They usually require a large amount of bandwidth for very short lapse
of time.
In more details, usually for each transaction the local system needs the receipt of the
acknowledgement from the remote site before continuing the operations. For minimizing the time
of transfer several tricks are used:
      high bandwidth to reduce as short as possible the serialization delay;
      not store and forward connections and short distances for reducing transmission latency;
      short distances between the two end-points of the data transfer.




                                           Page 41 of 48
                                    IST IP NOBEL "Next generation
                                                                                                 Title of the document
                                    Optical network for Broadband
                                         European Leadership"                              d3b95c2d-c84f-4997-a686-
                                                                                                 166859b24a5d.doc




The traffic generated from these kind of applications is a set of spikes using high bandwidth for a
very short lapse of time. For instance, the transfer of a SCSI block (e.g. 8kB) that, for minimizing
serialization time, is transferred over a 1Gbit/s interface, the time of the data transfer at the
interface might be calculated as follow:
        8kB = 64 kbit of row data
        Add 20% due on protocols overhead (e.g. SCSI, Fibre Channel or IP)                         [76.8 kbit]
        Add 8b/10b line code                                                                       [96 kbit]
                         96kbit
        The time is               96s
                        1Gbit / s
From these considerations it is obvious that it is impossible for this application to wait some
hundreds of ms to set-up/tear down connections for each data transfer that last less than 0.1 ms,
so the connection has to set-up before.
For mitigate this problem, it is suitable that a group of customers are connected to a “concentrator”
that may be a FC switch that is directly connected to a transmission device. Said “concentrator” is
a point where multiple clients share the same transmission connection (e.g. SDH VC-4) toward the
Storage Data Centre. To establish how many connections we have to set-up, it is necessary to
define:

        the amount of bandwidth necessary for a single customer (we assume that all the
         customers need the same bandwidth1)
        each customer is characterized by:
              o    belonging bandwidth
              o    frame transaction size
              o    numbers of transactions per hour.
        Fixed a maximum blocking probability Pb, assigned some customers to a single
         “concentrator”
              Pblock = f(number of customers,number of available connections)
              obviously the probability of blocking grows with the numbers of customers and
              decreases with the number of available connections.
              The number of necessary connections is the lowest number that verify:
              Pblock =f(customers,# of available connections) < Pb

                           2.5.3.2 Storage networking protocols
Another important point to take into account is the kind of native used protocols/technologies to
provide storage data transfer.



1
  This is not a restrictive hypothesis, because, in general it is possible to assume that all the customers need the same
bandwidth, independently with the dimension of the mirrored data-set. In fact, the amount of bandwidth is needed to
provide the serialization of the block, that has the same size for every data-set (8-10 kB). The size of data-set (and the
frequency of the operations) influences the number of spikes.



                                                    Page 42 of 48
                                   IST IP NOBEL "Next generation
                                                                                       Title of the document
                                   Optical network for Broadband
                                        European Leadership"                   d3b95c2d-c84f-4997-a686-
                                                                                     166859b24a5d.doc




                                                 SCSI commands



                                                                                iSCSI
                    Fibre Channel Fibre Channel Fibre Channel Fibre Channel

                                                                                TCP


                                       GFP-T        FC-BB-x_PW       FCIP         IP


                                        SDH              PW          TCP       Ethernet


                                                                       IP

                                                                    Ethernet


                                                   Physical layer


                        Figure 2.22: architectural model for storage networking


As shown in Figure 2.22, there are several modalities for carrying storage data across a
telecommunication network2, that have all in common SCSI (Small Computer System interface) as
logical protocol to provide storage commands.
Fibre Channel is a protocol suite standardizing the ISO/OSI layer, so that it is possible to use only
it to carry data. The limit of this solution is that it is really expensive because it is not possible to
use the public network or sharing transmission resources with other applications that don’t use
FC. For this reason, ever since the storage moved from an intra-office or campus scope to a
geographic range, it appeared necessary to encapsulate FC on protocols used for carrying
information across a network (e.g. SDH, TCP/IP or PseudoWire).
An emerging possibility is to not use Fibre Channel, but encapsulating directly SCSI commands
and data over TCP/IP, using TCP mechanisms to provide no data (packet) loss.
The alternatives depicted in Figure 2.22, inspecting the technical solutions from left to right the
performance and the cost decrease.
In the previous subsection some different kinds of applications, with different performance
requirements. The solutions presented in this section might satisfy all the requirements.
In more details, Fibre Channel only with Physical Layer (e.g. a WDM connection between the
primary and secondary sites) is addressed to very requiring solutions, such as Synchronous
Mirroring duplicating mission critical information produced with a very high rate because it is




2
    ESCON/FICON technologies are not consider in this study.



                                                  Page 43 of 48
                                  IST IP NOBEL "Next generation
                                                                                             Title of the document
                                  Optical network for Broadband
                                       European Leadership"                            d3b95c2d-c84f-4997-a686-
                                                                                             166859b24a5d.doc




essential a very short latency to stop primary system as short as possible3. Usually the connection
adopting FC directly over WDM is dedicated, and this increase the level of security.
FC over GFP-T to encapsulate FC frame on SDH provides in any case a circuit connectivity, but
GFP mechanism introduces a further (short) latency. This solution might be used by the
applications classified in DISK2, requirements QoS parameters less strong than the cases where
dedicated connection is necessary.
The possibility of use a pseudo-wire connection is not really used very often nowadays, but it can
be interesting to reach a compromise between latency performance and costs.
Another point of view is the use of IP network to transfer storage applications’ data.

FCIP
FCIP is a way of encapsulating FC frames within TCP/IP specifically for linking FC SANs over
wide areas. Instead of native IP connection between individual storage devices, FCIP provides IP
connections between Fibre Channel islands. IP addresses and TCP connections are used only at
the FCIP tunneling points.
FCIP devices do not perform IP routing or L3 switching. A couple of FCIP devices separated by an
IP network will appear simply as a couple of TCP end points.
When a Fibre Channel node on the SAN island needs to communicate with another nodes in a
remote SAN island, the FCIP gateway encapsulates the entire FC frame in TCP/Ip and sends it
across the IP network. At the receiving end, the IP and TCP headers are removed and a native FC
frame is delivered to the destination (Fibre Channel) node, through one or more (Fibre Channel)
switches.
The FCIP specification makes a few assumptions about the integrity of the wide area link,
including a low bit error rate and performance adequate for storage applications. Line quality,
transmission latency, class of IP routers bandwidth contention, and other factors determine how
much work TCP has to do to maintain data integrity.
For QoS over the IP network, FCIP might leverage enhancements to the IP header interpretation.
The differentiated services architecture (DiffServ) redefines the type of services (TOS field) in the
IP header to provide a differentiated service code point (DSCP).
DSCP defines a per-hop behavior in routers and switches that form the IP network.

iSCSI
FCIP is really not so much of an IP storage strategy as Fibre Channel extension and perpetuation
strategy. The iSCSI protocol represent a light switch approach to storage networking that, carried
to its logical conclusion, purges Fibre Channel from the notion of storage.
iSCSI uses TCP/IP for reliable data transmission over a potential unreliable network. In addition to
the normal TCP/IP transport, the iSCSI specification allows for a lower functional level on top of IP
to provide services such as IPSec data encryption.
One or more TCP connections are established to support an iSCSI session between SCSI initiator
and target. TCP ensures the orderly transport of the SCSI commands, status and data carried
within iSCSI packets (PDUs).



3
  It may be useful to remember that synchronous mirroring applications suspend the production of data at primary site
since a data is sent to the receiving of the acknowledgement of correct duplication on mirror (remote) site.



                                                  Page 44 of 48
                              IST IP NOBEL "Next generation
                                                                                  Title of the document
                              Optical network for Broadband
                                   European Leadership"                      d3b95c2d-c84f-4997-a686-
                                                                                   166859b24a5d.doc




The SCSI protocol demands stability, data integrity and requires high bandwidth (better if on-
demand). IP networks, in contrast, are inherently unstable, drop packets under congested
situations and have highly variable bandwidth.
The TCP layer is meant to deal with the instability and packet loss that may accompany IP,
whereas higher speed area connections can alleviate bandwidth issues for block storage data.
Imposing TCP overhead on the servers, for instance, is unacceptable for storage applications
where server CPU cycles are at a premium. For this reason iSCSI require TOEs (TCP Offload
Engines) to minimize processing overhead.
TOEs greatly assist iSCSI’s ability to provide enterprise-class solutions.


         2.5.4 TV – Broadcasting
National and international broadcast companies (like BBC in the UK) and production houses (like
Midnight Transfer, London) produce film and video content in a high technical quality. The high
quality is required to make the product (downward) compatible with the requirements in the world
wide market. If the production is in HDTV downgrading to any other format (even 4:3 standard TV)
should be possible.
Thus the production process generates huge amount of digital data which has to be moved
between studios and production companies. Most of this data exchange can be handled via
standard IP-based file transfer technologies. However, there is, in addition, demand for real-time
high speed transfer of audio-video data:
   For real-time events like sport events. The most demanding installation is currently being
    prepared for the 2006 FIFA World CupTM in Germany: All 12 soccer stadiums are connected
    with two times 10 Gbit/s to the production hub in Munich. Two uncompressed HDTV signals
    with 1,5 Gbit/s plus ten standard TV signal with 270 Mbit/s plus many compressed TV signals
    are multiplexed electrically and transported over standard WDM systems to Munich.
   For real-time events if no large time delay is acceptable (e.g. conferences, game shows with
    involvement of the audience)
   For real-time applications during the production process of a video. For real-time colour
    correction, for example, the data rate can be in the order of more than 2 Gbit/s if Fibre
    Channel based workstations are used.
Please note that all these real-time services are realized as an isochronous transport. It is
common to have packetized transport of the audio-video content, but it is not acceptable to have
packet re-transmission. Whether packet loss can be accepted depends on the concrete transport
equipment which might include some amount of error correction.
Typically, the broadcasters' networks are quite stable over time. There is small fluctuation only as
far as studios or production sites are considered. The traffic between these sites can be
characterized and subdivided as two different types of the demand:
   "Basic load traffic" caters for standard IP-based datacom applications, it also may include the
    distribution of program material towards satellite uplinks plus voice traffic.
   "Production traffic" is of bursty nature and is present only in some rather limited time-slots
Today dedicated, fixed configured SDH links and ATM networks are utilized for broadcasters. Due
to market pressure, network operators have to find alternative solutions in terms of products for
their customers, as well as in terms of a more cost efficient internal production of these services.
Lower layer VPNs are considered to be appropriate candidates for future solutions for



                                            Page 45 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




broadcasters. Further discussion on layer 1 and layer 2 VPNs can be found in the following
section of this deliverable.
It is well understood that broadcasters and production houses represent a small group of
professional network users. However, they can be considered as examples of customers requiring
high bandwidth and highly flexible solutions. If future telecommunication networks can cope with
broadcasters' requirements, other demanding applications can be tackled as well. Moreover the
advantages to integrate those services in the general network platforms of operators, instead of
providing solutions via dedicated networks are obvious.



         2.5.5 Video on Demand
VoD applications are inserted in the triple-play services announced word-wide as next service
demand. As described in D21, the introduction of VoD is expected to strongly impact on metro
access traffic. So, the provision of VoD services will be a key issue to be taken into account for
designing next generation metro networks. Network operators decisions related to VoD
provisioning must take into account some considerations that might greatly impact on metro traffic:
    Centralized vs. Distributed VoD servers. The hierarchical model of PoPs described in
     D21 may not be convenient for specialized distributors that perhaps choose Internet
     network or VPN to reach their costumers.
    Set Top Boxes (STBs): This parameter is of paramount importance not only for the QoS
     requirements but also for the traffic, kind of VC (or connections, in general) and so, for the
     design of metro networks to support peaks of video demands at a given hour. If the STB
     can hold an entire video in its internal memory, a typical xDSL access line (less than 10
     Mbps) can provide an efficient service for the subscriber to store the video within five
     minutes and then watch it on DVD (stop, reply, etc) conditions.



   2.5.5.1 Traffic Model for VoD service
In order to take decisions as those mentioned above (e.g centralized vs. distributed servers), we
need to develop a traffic model for VoD. In this respect we will consider the following assumptions:
    Users require 100% quality of service for VoD.
    The allocated bandwidth will be equal to the video peak rate, i. e. 6 Mbps assuming
     MPEG2 encoding.
    The average size for a movie is 300 Mbytes.
In order to mimic the user behavior we slot the time axis in 2-hours intervals. Then, a user will be
watching video with probability pv in the busy slot. Thus, a user will be occupying the video
channel for n slots with probability pvn(1-pv), i. e., the activity spurst for video are geometrically
distributed. The following figure shows the traffic model for video users




                                           Page 46 of 48
                              IST IP NOBEL "Next generation
                                                                                 Title of the document
                              Optical network for Broadband
                                   European Leadership"                     d3b95c2d-c84f-4997-a686-
                                                                                  166859b24a5d.doc




                                                              Busy slot
                                                                            User 1
                                  2h slots


                                                                            User 2




                                     Figure 2.23: Video models
This simple model is very suitable for dimensioning purposes in practical networks. Note that the
scenario for service provisioning is indeed competitive. Thus, operators are normally willing to
reserve full bandwidth to the end user, in order to ensure that he/she receives 100% quality of
service. This implies that either the channel is full or empty.
On the other hand we use the concept of busy slot as the counterpart for the busy hour in
telephone networks. In a country like Spain the busy slot for VoD may be 10-12 PM during
weekdays and 15-17 PM on the weekends. Note that the busy slot concept allows performing
worst case dimensioning. By dimensioning to the busy slot one can ensure a given quality of
service at any time.

   2.5.5.2 Scalability issues of first VoD implementations
First VoD the video-on-demand schemes used to work as follows:
    TV channels were broadcasted from the TV Headend to different Metro PoPs by means of
     the SDH backbone network.
    Users request either TV channels or VoD movies to single site (regardless of the number
     of VoD servers located at the site).
    Each movie request triggered an ATM PVC.
    Since multicast is not natively available in the ATM layer each TV channel or VoD movie
     occupied as many channels as users were requesting the TV channel or movie.
These implementations present important scalability problems. Next, we will use the traffic model
to demonstrate it.
Let us assume that the users are requesting movies with probability pv during the busy slot
(2hours) in movies/day per user. Let N be the number of users per video server. Since the
bandwidth per movie is 3 Mbps the probability density of bandwidth required at the video server
during the busy slot is


                                   P(rate=3x Mbps) = B(N, pv, x)


where B(N, pv, x) represents a binomial random variable with N users and parameter pv,
evaluated at x. The above expression can be used to find the number of users that can be served
with a video server of a given bandwidth. In order to estimate pv let us assume that, for the busy
slot (10-12 PM, for instance) a user will watch n movie per week. That means the pv=n/7. This
allows to characterize users with different activity degrees from light (1/7) to heavy (7/7 movies per
week). Let us assume that the user population is N=100 users. The following figure shows the



                                             Page 47 of 48
                                 IST IP NOBEL "Next generation
                                                                             Title of the document
                                 Optical network for Broadband
                                      European Leadership"               d3b95c2d-c84f-4997-a686-
                                                                               166859b24a5d.doc




necessary bandwidth to serve 100 users with 99% success probability, versus the probability pv
that reflects the user activity (1 movie/week, 2 movies/week, etc).



                                          Bandwidth versus pv

                           300
                       250
                 Band
                 width 200

                  (Mb/s)
                           150
                           100
                           50
                            0
                                   1         2         3         4      5
                                                      pv



          Figure 2.24: Video server bandwidth versus user activity (probability pv)
The figure shows that there is a linear increase in server bandwidth versus the user activity,
measured in movies/week. If all users are very active (5 movies per week) the necessary
bandwidth per server is 492 Mbps (for only 100 users!). Note that a 300 Mbps server will serve all
users with 100% QoS. On the other hand, for a 1 movie/week user this can be reduced to 138
Mbps.




                                             Page 48 of 48

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:10/19/2012
language:English
pages:48