1 / 5

Tomohiro Otani otani@kddilabs.jp Michiaki Hayashi mc-hayashi@kddilabs.jp

TE parameters to be exchanged between GMPLS-controlled ASes draft-otani-ccamp-interas-gmpls-te-00.txt. Tomohiro Otani otani@kddilabs.jp Michiaki Hayashi mc-hayashi@kddilabs.jp Satoru Okamoto okamoto.satoru@lab.ntt.co.jp. Summary of this draft.

quade
Download Presentation

Tomohiro Otani otani@kddilabs.jp Michiaki Hayashi mc-hayashi@kddilabs.jp

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

E N D

Presentation Transcript

  1. TE parameters to be exchanged between GMPLS-controlled ASesdraft-otani-ccamp-interas-gmpls-te-00.txt Tomohiro Otani otani@kddilabs.jp Michiaki Hayashi mc-hayashi@kddilabs.jp Satoru Okamoto okamoto.satoru@lab.ntt.co.jp 60th IETF San Diego August 2004

  2. Summary of this draft • This draft fits to the following charter item • “defining signaling and routing mechanisms to create paths that span multiple IGP areas, multiple ASes, and multiple providers”. • This draft • clarifies the need for dynamic or static TE information exchange between GMPLS-controlled ASes, comparing to MPLS networks. • describes the requirement of TE parameters for GMPLS EGP • is jointly proposed by SPs (KDDI/NTT) in order to improve operational efficiency for interconnecting GMPLS networks, while keeping their topology information concealing. [KDDI and NTT are interconnected with each other at L1 (SONET/SDH), L2(ATM) as well as at L3 (IP).] 60th IETF San Diego August 2004

  3. GMPLS Inter AS TE overview GMPLS AS 1 GMPLS AS 2 Based on GMPLS constrains LSC LSC LSC LSC • In addition to the constraints considered in the MPLS Inter AS network model, the GMPLS Inter AS network model should consider the following constrains: • Switching capability of nodes: TDM-SC, LSC, FSC • Encoding type of TE links: Ethernet, SONET, Lambda, etc. • Bandwidth of TE links: 1G, 2.4G, 10G, 40G, etc. • SRLG of TE links as well as nodes (Protection type: 1+1, 1:1, unprotected, etc) • These are used to appropriately establish a GMPLS LSP across multiple ASes, while keeping the topology information concealing. LSC/SONET/2.5G LSC LSC LSC LSC AS 1’s view LSC/SONET/10G LSC LSC LSC LSC Shortest path Ingress (2.5G SONET LSP) Egress AS boarder nodes determined by SPs’ business strategy 60th IETF San Diego August 2004

  4. Requirement of TE parameters for GMPLS EGP • GMPLS boarder nodes are required to announce an end-point (reachability) list consisting node IDs, interface addresses and interface IDs per following parameters; (1) Interface Switching capability (1-1) Bandwidth A. Total link bandwidth B. Max./Min. Reservable bandwidth C. Unreserved bandwidth (1-2) Switching capability: TDM, Lambda, FSC (2) Bandwidth Encoding: Ethernet, SONET/SDH, Lambda, etc. (3) SRLG (otherwise, protection type may be added) • In addition, in order to create resilient LSPs over ASes, a mechanism to assign globally unique SRLG IDs across multiple ASes may be required (ex. part of the bits is locally controlled and part is globally controlled). 60th IETF San Diego August 2004

  5. Next Steps • Will add the GMPLS EGP requirements. • Need EGP experts to help describe EGP requirements. • Investigate the extra load of ASBRs by introducing GMPLS EGP extensions (suggested by Adrian). • Will propose this to be a working group document after the above work is completed. • Will investigate GMPLS EGP extensions. • Need EGP experts to help develop GMPLS EGP extensions. • Will investigate the bit assignment mechanism in SRLG to maintain a global consistency. 60th IETF San Diego August 2004

More Related