Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Computer network wikipedia , lookup
Distributed firewall wikipedia , lookup
Passive optical network wikipedia , lookup
Deep packet inspection wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Airborne Networking wikipedia , lookup
Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN draft-ietf-l3vpn-e2e-rsvp-te-reqts-01.txt Kenji Kumaki KDDI R&D Labs, Editor Raymond Zhang BT Yuji Kamite NTT Communications July 2008 72th IETF@Dublin Major Changes from -00 • Clarified problem statement in Section 3 – Last IETF, Yakov asked a question about the scalability of CTE LSPs • Added application scenarios for RSVP-TE over NonTE LSP in section 5.6 • Added specific requirements for admission control support for C-TE LSPs in LDP-based core networks in section 6.6 July 2008 72th IETF@Dublin Problem Statement • C-TE LSP model (data packets among CEs are forwarded by "labeled IP packets ") – If service providers offer a C-TE LSP from CE to CE over BGP/MPLS VPNs, they require that a MPLS TE LSP from a local CE to a remote CE be established. However, if a C-TE LSP signaling is to send within VPN, the service provider network will face scalability issues. – A C-TE LSP can be aggregated by a P-TE LSP at PE. (i.e. hierarchical LSPs) In this case, only PEs maintain state about customer RSVP sessions. – A C-TE LSP can not be aggregated by a P-TE LSP at PE depending on some policies. (i.e. continuous LSPs) In this case, both Ps and PEs maintain state about customer RSVP sessions. – A C-TE LSP can be aggregated by non-TE LSP (i.e. LDP). In this case, only PEs maintain state about customer RSVP sessions. Note that there is always enough bandwidth available in service provider core network. July 2008 72th IETF@Dublin RSVP-TE over Non-TE LSP C-TE LSPs non-TE LSPs (LDP) Vrf instances CE C CE PE C PE P P CE CE PE PE Customer’s or Customer’s or another SP’s network July 2008 Service Provider’s network 72th IETF@Dublin another SP’s network Specific Requirements • Admission Control Support for C-TE LSPs in LDP-based Core Networks – PEs MUST have a configurable limit on the maximum amount of bandwidth that can be reserved by C-TE LSPs per a vrf instance (i.e. per a customer). Also, a PE SHOULD have a configurable limit on the total amount of bandwidth that can be reserved by C-TE LSPs between PEs. PE PE PE C-TE LSPs vrfs vrf ・・・ C-TE LSPs vrfs PE Limit on the maximum amount of bandwidth July 2008 C-TE LSPs Limit on the total amount of bandwidth 72th IETF@Dublin vrfs C-TE LSPs Next Steps • Will add application scenarios based on comments • Stitching LSPs • CE-PE: C-TE LSPs • PE-PE: non-TE LSPs (LDP) • PE-CE: C-TE LSPs July 2008 72th IETF@Dublin