• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
  • 對在公用ATM網絡上傳送IP解決方案的要求

    發表于:2007-05-26來源:作者:點擊數: 標簽:
    本文依據針對MPLS的 解決方案 提出的建議草案I.ipatm,首先介紹了公用ATM網上傳輸IP的總體要求與體系結構,隨后對目前推薦采用MPLS解決方案的原因進行了簡要分析。 已采用ATM(異步轉移模式)技術的運營商,面對IP業務的飛速發展,正在積極尋求使用ATM傳送IP

    本文依據針對MPLS的解決方案提出的建議草案I.ipatm,首先介紹了公用ATM網上傳輸IP的總體要求與體系結構,隨后對目前推薦采用MPLS解決方案的原因進行了簡要分析。
      
    已采用ATM(異步轉移模式)技術的運營商,面對IP業務的飛速發展,正在積極尋求使用ATM傳送IP的最佳方案。目前普遍認為MPLS(多協議標記交換)是未來公用骨干網的解決方案。MPLS首先將在公用ATM骨干網上引入。它采用集成模式,將IP技術與ATM技術良好地結合在一起,從而兼具了ATM的高速性能、QoS(服務質量)性能、流量控制性能與IP的靈活性、可擴充性,它不僅能夠解決當前網絡中存在的大量問題,而且能夠支持許多新的功能,所以是一種較為理想的骨干IP網技術。作為國際電信標準的權威ITU-T已將IP標準的研究放在首位,1999年9月SG13的IP專家組會議針對采用MPLS的解決方案提出了公用ATM網上傳送IP的建議草案I.ipatm。全面提出了網絡的總體要求、網絡體系結構、協議體系結構和業務映射的要求等,并對推薦采用的MPLS解決方案作了明確的說明。本文將對該建議草案的主要內容作一概括的介紹。

    1網絡總體要求
    本節對于各種ATM傳輸IP的技術提出了一些總體要求。這些要求對于所有確定的IP業務都是適用的。下面各項是強制性的要求:

    網絡的技術方案必須獨立于所支持的IP協議版本;
    網絡的技術方案必須具備支持大型網絡的足夠的可擴展性;
    網絡的技術方案必須包含在ATM網絡上支持高效而且具有可擴充性的IP組播的能力;
    網絡的技術方案必須具有足夠的魯梆性以便支持大型網絡。

    2網絡體系結構
    在ATM上支持IP層業務的框架體系結構被定義為支持IP業務所需的網絡體系結構與協議體系結構的結合。

    2.1網絡結構
    IPOA的參考網絡結構如圖1所示。該配置顯示了支持IP業務的各種可能的情況。虛線框顯示的是公共網。在本文中所涉及的公共網僅限于具有ATM核心的公共網。虛線框中的方框顯示的是公共網中的一般配置。它們包括ATM核心,IPOA網絡與邊緣路由器。虛線框外是一些不同的網絡,它們顯示了公共網向各種特定網絡提供各種特定的IP業務的情況。從公共網的角度來看,這些網絡都可以認為是用戶網絡。






    注:
    1:Internet服務提供商可能也提供ATM核心。
    2:第1類與第2類參考點可以是ISDNS,T等標準化的參考點,也可以是非標準化的接口。
    圖1IPOA參考網絡結構

    圖2.2顯示了公共ATM網絡與專用ATM網上IP業務的參考配置。在專用與公共IPOA網絡中,IP業務是利用ATM的交換功能與IP的業務功能(IPSF)來實現的。在這種情況下,ATM交換功能與IP業務功能之間的接口應該定義在P或者是M參考點上(參見建議I.364)。IP業務功能(IPSF)指的是實現IPOA所需的功能。IPSF的一個典型例子就是地址解析業務。作為一種終端系統,IPSF實際上就是一臺具有ATM接口的路由器。




    圖2:ATM上實現IP業務的參考配置

    IPSF功能與ATM交換功能可以在同一設備上實現。在這種情況下就沒有必要定義參考點P上的接口了。IPSF功能與ATM交換功能也可以分別在不同的設備上實現。在這種情況下,對與M或P點上接口的定義依賴于IPSF是在核心ATM網絡里面還是外面。
    ATM網絡之外的ISP與終端系統(ES)可以接入專用或者是公共ATM網絡。每一終端系統都有一套完整的IPOA協議棧,若與專用IPOA相連,則使用專用UNI,若與公共IPOA相連,則使用公共UNI。
    2.2網絡與業務互通
    在網絡互通環境中,借助于兩個網絡之間的互通功能(IWF),IP協議控制信息(PCI)與載荷數據可以通過ATM網絡被透明地傳輸到另外一個IP網絡。典型的情況是,IWF僅僅使用一種適配功能對IP分組進行封裝并將其透明地傳到遠端IWF。
    對于現有的IP與ATM網絡的互通,典型的情況是網絡互通,亦即由ATM提供骨干或者是核心網絡來傳輸IP協議。在這種情況下,ATM網絡可以看作是第三層(與更高層)協議的下層傳輸。
    對于業務互通的情況,IWF終止IP協議的傳輸并將PCI翻譯為ATMPCI,以便實現傳輸控制與管理等功能。由于在一般情況下,并不是每個網絡都能夠支持所有的功能,業務互通功能可以只是在兩種技術之間進行一種最佳轉換。然而,這種轉換不會造成任何的用戶數據丟失,因為互通IWF上的PCI轉換不會影響用戶數據。前面圖1與圖2顯示了與IPOA有關的網絡互通。

    3協議體系結構
    3.1ATM傳送IP協議參考模型的一般描述
    圖3描述了公共網中在ATM上傳送IP的協議參考模型。要注意的一點是下層的關于層管理、平面(或系統)管理與控制平面的概念都得到了擴展以便包含第三層及以上層的功能塊。圖3中顯示的模塊只是各種功能的邏輯表示,所以這些模塊并不是對具體的物理實現的規定。功能模塊之間的接口可以是內部的子層或平面之間的非標準化通信接口,也可以是外部的標準化協議接口。
    通用模型中的每一層次都有對應的層管理功能模塊。層管理功能模塊只負責該層管理與協議控制信息(PCI)的處理。層次間的通信只能通過平面管理功能進行。這一功能通過平面管理中的協作功能(CoF)模塊來執行的。
    IPOA的各種網絡應用中不需要都包含所有的功能模塊。這樣,上述功能模塊可以看作是實現各種特定的網絡(或NE)應用的基本“構件”。然而,必須保持不同模塊之間的基本關系與順序以便保證一致的可操作性。



    圖3:IPOA協議參考模型

    3.2IPOA協議參考模型的功能性描述
    3.2.1IP-SSCS/AAL5功能
    IP-SSCS/AAL5功能模塊集成了將IP負載映射到AAL5上所需的各種傳輸功能,該模塊提供了RFC1483中IETF采納的,基于IEEE802.2的鏈路層控制/子網附加點(LLC/SNAP)協議中定義的封裝與多協議復用功能。

    3.2.2IP層功能
    IP層的功能提供了通過一個互通的系統實現源到目的地的IP轉發(IP數據報傳送)的能力。IP轉發指的是接收到一個分組后,使用一種開銷很低的判決過程決定如何處理該分組的過程。對分組可以本地傳送或外部轉發。對于進行外部轉發的業務量,IP轉發過程還要決定IP分組的發送接口,而且如果有必要的話,還可以除掉一層媒體的封裝而代之以另外一個,或者是對媒體層封裝中的特定域加以修改。
    IPOA協議的結構必須獨立于IP的版本。目前,IP有兩個版本,IPv4(IP版本4)與IPv6(IP版本6)。IP層的功能應與IETF在RFC791與RFC2460(分別對應于IPv4與IPv6)中的定義相同。
    IP層的功能并不能提供一種可靠的通信設施。傳輸過程中,無論是端到端還是每一跳之間都沒有確認過程。
    應該注意的是,在ATM上使用SSCS/AAL5功能時,不應改變IP層的功能。
    3.2.3IP層管理功能
    IP層管理有兩種基本功能:尋址與分段。IP層功能使用IP頭標中攜帶的地址將IP數據包發送到目的地。對于傳輸路徑的選擇使用的是信令與路由功能模塊。如果有必要的話,IP層功能還將利用IP頭標中的特定域來對IP數據包進行分段與重裝。
    IPv4主要使用4種機制來提供它的業務:服務類型,生存期,選項,與頭標校驗和。IPv6是Internet協議的新版本,是對IPv4的升級版本。新版本中的變化主要有下面四個方面:擴展的尋址能力,頭標格式的簡化,對于擴展與可選功能支持的提高,流標記能力與認證、保密能力。
    IP層管理功能并不對數據提供差錯控制,除了在頭標中有一個校驗和之外。協議中沒有重傳與流控機制。

    3.2.4傳輸層功能
    傳輸層包括面向連接型的TCP功能與無連接型UDP功能。這依賴于應用程序的類型。
      TCP功能為進程之間提供可靠的連接。TCP功能與IETF在RFC793中的定義是一致的。TCP功能包括下列設施:基本的數據傳輸,可靠性,流控,復用,連接,優先級與安全。
    UDP功能提供的是數據報傳輸。UDP功能與IETF在RFC768中的定義是一致的。UDP是面向事務的,傳輸與重復保護是沒有保障的。在ATM上使用傳輸層功能時不應改變傳輸層功能。

    3.2.5應用層功能
    應用層與相關的層管理功能模塊包括用戶與網絡特定的應用,例如HTTP,FTP,TELNET等。對于應用層功能的描述不在本建議的范圍之內。
    注意在TCP/IP協議結構中,應用層功能一般包括了會話與表示層的功能。
    3.2.6網絡管理功能模塊
    網絡管理功能依賴于特定的IPOA網絡應用。通常,它們包括與下面的管理有關的一些TMN功能:故障管理、性能管理、配置管理、安全管理等。
    3.2.7信令與路由控制功能
    這一功能包括了IP與/或ATM控制中的信令與路由功能模塊。IP控制與信令包括了含選路在內的各種IP控制。ATM控制包括了ATM信令與選路。

    4IP業務
    IP業務是通過“用戶”與“提供者”之間的接口以IP(因特網協議)包(數據包)形式傳送數據的一種數據傳輸業務。在這種情況下,提供者不必知道IP包內的數據屬性?!坝脩簟迸c“提供者”之間實際或隱含的契約是“提供者”對凈荷內容不加更改(控制域可以改變或不變)地將IP包傳送到目的地(一個IP地址或另一個運營者/用戶接口)。該契約可以隱含一組由用戶在向提供者提出會話請求時指定的傳送質量參數(如BER、端到端延遲、序列正確與否等)。實際中,可以采用指定IP包攜帶數據屬性的“速記”方式指定這些參數。例如,如果“用戶”指定這些包攜帶話音,則可以直接映射到一組特定的傳送質量參數。但是應當注意,這種情況不同于用戶請求一次話音呼叫,允許但實際上是期望提供者將用戶數據作為話音數據處理,例如,進行變換編碼和/或在TDM設施上承載數據,此種情形是話音業務而不是IP業務。
    4.1IPIntserv技術
    Intserv是根據每個IP流的QoS等級的精確描述,由具有RSVP功能的路由器中的RSVP協議和流的接納控制支持IP的QoS分類。
    在Intserv流中,定義了兩類業務――保證業務(GuaranteedService—GS)和受控負載業務(ControlledLoadService--CLS)。對于GS業務,流的最大排隊時延是受到控制的,路由上的任何時延都會影響最大排隊時延。而CLS沒有固定的時延保證,但業務流要與在網絡輕載情況下的流質量相當,實際上CLS要求有長期的帶寬保證??傊?,這兩種業務都要求用令牌漏斗協議來定義流的特性,超出的業務流被當作“盡力而為”型業務量處理

    4.2IPDiffserv技術
    IETF的diffserv模型是基于每跳行為(PerHopBahaviors――PHB)的概念,diffservPHB由路由上的每個本地路由器所具有的前轉行為來定義。目前,IETF已定義兩種主要的PHB:
    加速前轉(EF)PHB(ExpeditedForwardingPHB—EFPHB)
    EF-PHB的特征是帶寬具有可配置性并在同一鏈路上不受其它業務量的影響。EF-PHB可以用來在Diffserv域中建立要求具有低丟失率、低時延與低時延抖動的端到端業務。
    可確定的前轉(AF)PHB組(AssuredForwardingPHBGroup—AF-PHB組)
    AF-PHB組的特征是有四個AF等級,給每個等級分配一定量的轉發資源(比如在一個Diffserv節點上的緩存與帶寬等)。在每一個AF等級中,各個IP分組被標記上三種可能的丟棄優先級。當發生擁塞時,分組的丟棄優先級將決定在某一AF等級中各分組的相對重要性。然而,在四個AF等級的相對性能之間沒有標準的關系。AF-PHB組可以實現以較高的可能性保證業務所要求的信息速率。

    4.3業務映射功能清單
    業務映射功能不依賴于周圍的網絡結構而只依賴于需要進行映射的界面兩側支持IP與ATMQoS的方式。圖4顯示了我們考慮的網絡結構中所必需的IP業務到ATM業務映射的各種可能的組合。



    圖4業務映射功能清單

    對于ATM支持IP將只解決映射6和映射12,而且只要是在IP/ATM混合的網絡中要在ATM部分上支持BestEffort以外的IP業務,就需要有這兩種映射。注意,在這種情況下,在ATM部分的網絡出口上,并不需要有第5與第10種映射功能,這是因為在目的地IP網絡中,對于QoS的支持是完全基于IP信息的(比如,RSVP消息或者是IP分組中DS域),而這些信息是由ATM網絡透明地傳輸的。當本地的ATM業務量必須經由一個純IP網絡傳輸或者目的地就是一個純IP網絡時,將可能需要有第5與第10種映射功能,這一點還有待進一步研究。
    第3與第4種映射功能只屬于IP區域,對它們的研究是IETF工作的一部分。同時,起始于/終止于擴展ATM參數與QoS等級的所有映射都屬于是ATM論壇的工作(在ATM專網中支持)。

    4.4將IP集成型業務映射到ATM業務
    當連接兩個有Intserv能力路由器的ATM連接必須支持有GS[RFC2212]或者CLS[RFC2211]要求的IP流時,就會產生將IP集成型業務映射到ATM業務的問題。而這一問題與在ATM支持IP的特定技術無關。預計將有兩種映射方式:一對一映射和多對一映射。

    4.4.1一對一映射
    當一個ATM連接完全用于支持一個IP流時,將使用一對一映射。從嚴格的角度講,映射過程包括對可以滿足IP業務QoS承諾(GS或CLS)的ATM業務(即,ATC與相關的QoS等級)的選擇,從這種角度來看,可能有好幾種映射。然而,從較寬泛的角度來看,映射過程可以進一步被看作是一種按照承載的流的特征,向ATM級傳輸盡可能多的信息的方式,這樣,下游的ATM網絡將可以根據這些信息來承載某一連接(例如,將連接與其它連接復用)。從這一角度看,可以對各種可能的映射進行分級,確定其中的一些映射是優于其它映射的。

    4.4.2多對一映射
    當一個ATM連接可以支持不止一個IP流時,將使用多對一映射。在這種情況下,映射的過程將包括在對于可以支持一組IP流的QoS承諾的ATM業務的選擇中。因為IP流的起始與終止一般都是異步的,這一映射過程可以看作是一種基于IP級的(令牌桶與QoS要求)流描述之上的CAC過程,這一過程將依據在一條業已存在的ATM連接上將一個流與其它已有的流一并傳輸的可能性或者是對連接參數重新進行協商的需要作出決定。
    5推薦采用的網絡解決方案
    建議采用MPLS作為公共網中在ATM上支持IP的最佳技術。MPLS支持目前所確定的IP所有業務。選擇MPLS作為最佳技術的原因主要包括:
      1適應于較大規模的網絡。眾所周知,MPOA非常適用于小規模的網絡,然而應用于較大規模的網絡就要受到限制。而MPLS正是為滿足大規模網絡的各種要求(如靈活性,可擴充性與可管理性等要求)而設計的。
      2適應于多種承載網絡。大規模的網絡可以使用包括ATM在內的多種承載技術。從一個較寬的范圍來講,應該選取一種對于IPOA是最優,而且對于其它的鏈路層技術也是最優的技術。而MPLS則可能正是能夠覆蓋這一范圍的唯一技術。
      3路由控制的靈活性。從選路的角度來講,MPLS技術可以使我們獲得同時選擇使用固定路由或者是動態路由方式的可能性。具體使用哪種方式取決于網絡操作者的選擇。
      4能同時支持MPLS和ATM控制協議。較理想的情況是有一種獨立于鏈路層協議的控制技術。同時,同一交換機上也可以使用ATM控制,這種情況稱為“shipsinthenight”方式。
      5 IP業務的業務量工程。目前,ATM擁有最完整的業務量工程能力。然而,IPOA的重疊模型無法高效地使用所有的ATM能力,而且在使用全連通的PVC方式時,其應用的可擴充性將受到N平方問題的限制。MPLS借用了一些ATM技術的能力,如QoS、選路、資源管理等方面,而且引入了顯式路由的概念,它有助于將業務量要求映射到網絡拓撲之上。這樣,使用MPLS可以獲得新的,更多的業務量管理性能。
      6利用現有投資??紤]到現有的ATM與其它技術的投資,另外,在各種鏈路層技術上傳輸IP的需求也是顯而易見的,所以需要有一種同一的交換技術。當前的承載網絡中,ATM硬件對IP業務量的傳輸使用的是一種固定方式,而MPLS則被認為是CIPOA近期的演進方向,因為顯式選路可以建立在現有固定PVC的基礎上,而且MPLS網絡結構的靈活性足以滿足潛在的網絡演進需求。
      7支持VPN業務。MPLS的主要優點是能夠以無連接方式或者是顯式路由方式提供面向連接的業務,這種特點使得MPLS尤其適用于動態隧道技術。而動態隧道技術是目前支持VPN業務的有效傳送手段。但目前由于提供基于MPLS的VPN的方式不是唯一的,這使得將它同其它IPOA技術進行比較較為困難。
      8 QoS方面。IPDiffserv與MPLS具有明顯的默契,因為它們的設計中都滿足了業務提供商的需求。由于標記的擴展語義可以攜帶Diffserv信息,借助于標記與端到端的標記交換路徑及一定的資源預留機制,將可以保證QoS機制在特定MPLS域中的一致性。


    作者簡介
      趙慧玲1982年畢業于北京郵電大學,碩士生導師?,F任電信傳輸研究所副所長、信息產業部郵電科技委委員、國家網絡與交換標準研究組主席、國家863通信主題信息網專業專家組成員、信息產業部電信研究院網絡戰略研究組成員、全國青聯委員。1999年被國家人事部授予“中青年有突出貢獻專家”的稱號。從事寬帶網技術標準和ISDN技術的標準與測試工作,曾撰寫有8部技術專著。

      吳江1992年考入上海復旦大學電子工程系電子學與信息系統專業,1997年畢業后進入原郵電部電信科學研究院就讀研究生,在電信傳輸研究所主要從事IP及ATM相關領域方面的研究。

    原文轉自:http://www.kjueaiud.com

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>