PBB Network Scalability mp2mp B-VLAN. Maarten Vissers March 2007

Transcription

1 P Network Scalability mp2mp -VLN aarten Vissers arch 2007

2 802.1ah P PIP, CP and PP on I- and -Components Current design S-EPs not shown Customer-C address space Provider-C address space S-VLN C Relay S-IPs S-Tag Type?, -D/-S I-EPs I-LN EP Provider Instance Port I-EPs I-IPs I-EPs I-LN EP P I- Switch Cust ackb Port I-EPs I-IPs I-EPs -EPs -Component P -VLN C Relay -EPs Set of -VLN end points in CP dedicated to Service Instance set in one CP interface VIP: Virtual Instance Port, : Trunk Instance Port, : Link Instance Port -IPs -EPs -Tag -LN EPs Provider ackbone Ports 2 P -VLN scalability arch 2007

3 802.1ah P CP and PP on -Components and Cs Current design P I- Switch I-EPs I-EPs I-IPs I-IPs I-EPs I-LN EP Cust ackb Port I-EPs -EPs P -VLN C Relay -EPs -Component P -VLN C Relay -EPs -IPs -IPs -EPs -EPs -Tag -LN EPs Provider ackb Ports Provider ackbone Ports -Tag -LN EPs VIP: Virtual Instance Port, : Trunk Instance Port, : Link Instance Port 3 P -VLN scalability arch 2007

4 P mp2mp -VLN scalability issue 1 ssume that a P network domain is bound by 50 -Es. Those 50 -Es are interconnect with each other via intermediate Cs, while many I-Es are connected to the other side of those -Es. ssume that a -E has ten interface cards, each having ten CP functions. -E (in this example) may thus have up to hundred CP functions. The 50 -Es at the edge of the P network domain may have up to 5000 CP functions. [Note - current interface cards may have up to 48 interface ports.] Worst case, a -VLN will have a service mix which has one end point of its service instances behind each CP function. Such -VLN # (e.g. =100) will then have a total of 5000 end points and VLN EPs. With VLN EPs, each generating CCs with 100 ms periodicity causes each of those EPs to receive 4999 x 8 kbit/s = bit/s of CC frames. With ten -VLN # EPs on an interface card, the interface card will receive 10 x = bit/s of CC frames for -VLN #. Idem for other -VLNs (#Y, #Z, etc). Question: How to reduce the number of -VLN end points? 4 P -VLN scalability arch 2007

5 P mp2mp -VLN scalability issue 2 P contains a service instance layer and a -VLN trunk instance layer. The objective of the introduction and use of a trunk layer in transport networks is to have the nodes within the trunk domains independent of the service instances. Service instance awareness will then be restricted to the trunk domain edges. C nodes will then only have to deal with trunk instances, of which there are typically a factor of 50 to 100 less then service instances (e.g. 1 million service instance, 10 to 20 thousand trunk instances with most of those located in the metro domains and just some 10 to 20% in the core domain). Comparing the above trunk layer objective with the use of the -VLN trunk instances inside a P network domain, it can be concluded that the -VLN trunk layer does not meet the objective. Every -VLN needs to take into consideration the service instances carried over it; i.e. it needs to be aware and has to administer unicast C addresses and multicast C addresses. With at least one multicast C address per multipoint service instance, and networks that may have up to 30% multipoint services, it will not be uncommon that multicast C addresses are to be registered within a core domain; i.e. within C nodes inside the core domain. When an inner core node fails or a major cable breaks there are then many multicast addresses to re-register within the restored -VLNs. Question: How to reduce service instance awareness within the -VLN? 5 P -VLN scalability arch 2007

6 inimize mp2mp trunk instance (-VLN) end points Current: One -VLN # end point per CP interface port aximal n x m in -Component m: # interface ports per CP interface card n: # CP interface cards in -Component k: # -Components per P Network maximal n x m x k -VLN # end points per P network; e.g VLN # end points and thus EPs lternative I: One -VLN # end point per CP interface card; aximal n in -Component maximal n x k -VLN # end points per P network; e.g VLN # end points and thus 500 -EPs lternative II: One -VLN # end point in -Component (on PP interface card) maximal k -VLN # end points per P network; e.g. 50 -VLN # end points and thus 50 -EPs 6 P -VLN scalability arch 2007

7 Current -E equipment architecture -E includes one or more PP interface cards one or more CP interface cards one or two -VLN C Relay fabric cards PP interface card includes one or more Provider ackbone Ports (optional) multiplexer to access fabric CP interface card includes one or more Customer ackbone Ports (optional) multiplexer to access fabric CP I/E P s S W I T C H I/EPs I/EPs I/EPs EP EP EP V L N CP CP CP CP CP CP CP CP CP - V L N C R E L Y -E PP PP PP PP PP PP 7 P -VLN scalability arch 2007

8 lternative -E equipment architecture (I) Split CP into two parts (I: interface) module CP-C (C: common) module odified CP interface card includes -E one or more modules one CP-C module I/E P s I/E P s S W I T C H I/EPs I/EPs I/EPs CP-C EP EP EP V L N CP-C CP-C CP-C - V L N C R E L Y PP PP PP PP PP PP 8 P -VLN scalability arch 2007

9 lternative -E equipment architecture (II) Relocate CP-C module (from CP interface card to PP interface card) odified CP and PP interface cards CP: one or more modules PP: one or more CP-C/PP modules C Relay forwards s 9 P -VLN scalability arch 2007 I/E P s S I C R E L Y -E CP-C/PP CP-C/PP CP-C/PP CP-C/PP CP-C/PP CP-C/PP I/EPs I/EPs I/EPs CP-C/PP EP EP EP V L N

10 P I- C Relay technology availability C Relay function on basis of I-D and -D Every years fabrics support factor 4 more instances 802.1Q-1998: 4k, today (2007) 4k x 64 = 256k should be possible especially as number of -Ds to learn is limited to one per mp service endpoint 70% of service instances is p2p, not requiring C learning as such, restricted number of service instances with restricted number of Ds 24-bit I-D may not be significant in first years of deployment like in early days T, restrict use to k-bit (k<24) vailability of technology agnostic switch fabrics supports SDH, OTH, PLS and Ethernet use of 16- to 20-bit instance identifiers, supporting 64k to 1 switched/bridged instances C-VIDs, S-VIDs, -VIDs, I-Ds mapped onto equipment specific instance identifier at ingress port and vice versa on egress port 10 P -VLN scalability arch 2007

11 inimize service instance awareness in -VLN trunks Current: individual Provider-C (-C) address registration one per PIP one per CP (if Service Instance EP active in CP) registration method: C learning group Provider-C (-C) address registration one per mp2mp or rooted-mp Service Instance registration method: RP or other protocol lternative: zero Provider-C address registration method: p2p -VLN trunks best with lternative II -E design etro P domain Few hundred trunk instances no problem to deploy p2p -VLNs Core P domain Few hundred to ten thousand trunk instances no problem to deploy p2p - VLNs together with some restricted -VID Translation 11 P -VLN scalability arch 2007

12 Current service instance awareness in n-port -VLN trunks rationale consequence remedy complexity General multipoint-to-multipoint rationale: prevent multiple copies of multicast frame to occur on a link (resource bandwidth optimization) consequence: extended flooding scope for every broadcast, multicast and unknown unicast service instance frame (decreases resource bandwidth utilization) remedy: install flooding restriction methods: P -VLN service instance awareness (pc address administration) additional service instance associated state to limit flooding one individual pc address per PIP (one or more VIPs) one group pc address per n-port service instance P service instance pre-conditioning at Trunk Instance Ports () multipoint service instance: translate all-group and unknown individual/group pc addresses into service instance specific group pc address point-to-point service instance: translate all-group pc address into individual pc address of destination VIP lternative service instance pre-conditioning perform pre-conditioning at Virtual Instance Ports (VIP) additional configuration effort, possibly including additional cc pc learning superfluous complexity outside n-port trunk solutions 12 P -VLN scalability arch 2007

13 Current service instance awareness in n-port -VLN trunks rationale consequence remedy complexity pplication specific rooted-multipoint aggregation service P -VLN service instance awareness (pc address administration) additional service instance associated state to limit flooding one individual pc address per PIP (one or more VIPs) P service instance pre-conditioning at or VIP point-to-multipoint broadcast TV distribution (root to leaves only) minimized resource bandwidth utilization service instance unaware (broadcast only) Defeats trunk layer objective, except for point-to-multipoint Solution (mp2mp trunks) worse than problem (multiple copies on link) 13 P -VLN scalability arch 2007

14 Zero service instance awareness in 2-port -VLN trunks Completely independent of P service instances Trunk instance identifier administration only no ackbone-c addresses to register (and learn/age) in C nodes Complies with trunk layer objective inimized VIP/ configuration and processing unrestricted use of all-group ackbone-c address no need for Service Instance specific group ackbone-c address (per VIP) no need for 802.1ah OI no need for Default ackbone-c address entry in service instance table in CP no need to replace all-group ackbone-c address by Default ackbone-c address no need to change CF group C address usage 14 P -VLN scalability arch 2007

15 est scalable P -VLN architecture lternative II -E architecture with 2-port -VLN trunks 15 P -VLN scalability arch 2007

16 ackup

17 ultiple PIPs in I-E, multiple CPs in -E I-Component S-Tag Type?, -D/-S S-VLN C Relay S-IPs I-EPs I-LN EP Provider Provider Instance Instance Port Port Provider Instance Port I-EPs I-IPs I-EPs I-LN EP Cust Cust ackb ackb Port Port Cust ackb Port P I- Switch P I- Switch P I- Switch I-EPs I-IPs I-EPs -EPs -Component P -VLN C Relay -EPs Set of -VLN end points in CP dedicated to Service Instance set in one CP interface ultiple CP interfaces multiple sets of -VLN end points (degrades scalability) -IPs -EPs -Tag -LN EPs Provider ackbone Ports VIP: Virtual Instance Port, : Trunk Instance Port, : Link Instance Port 17 P -VLN scalability arch 2007 C Service oundary VIP I-EP -EP LN-EP S-IP I-IP -IP S relay I switch relay

18 ulti-interface CP Discussed in onterey on Friday I-Component S-VLN C Relay S-IPs S-Tag Type?, -D/-S I-EPs I-LN EP Provider Provider Instance Instance Port Port Provider Instance Port I-EPs I-IPs I-EPs I-LN EP Customer ackbone Ports multi interface CP with P switch/relay one set of -VLN end points per CP interface card P switch per interface card (forwards on basis I-D, possibly also on -D?) -Component has one -VLN # end point per i/f card Thus still many (but fewer) -EPs for # P I- Switch [C Relay?] P -VLN C Relay -EPs -IPs -EPs -Tag -LN EPs I-EPs I-IPs I-EPs -EPs -Component Provider ackbone Ports VIP: Virtual Instance Port, : Trunk Instance Port, : Link Instance Port 18 P -VLN scalability arch 2007

19 Single Switch/Relay -Component inimized number of -VLN end points I-Component S-VLN C Relay S-IPs S-Tag Type?, -D/-S I-EPs I-LN EP Provider Provider Instance Instance Port Port Provider Instance Port I-EPs I-IPs I-EPs I-LN EP Cust ackbone Ports Customer ackbone Ports central P relay, -VLN termination on PP set of -VLN end points per node P relay per node (forwards on basis I-D and -D) -Component has one -VLN # end point per node inimized number of -EPs -Component P I- C Relay Provider Provider ackbone ackbone Ports Ports* I-EPs I-IPs I-EPs -EPs -Tag -LN EPs VIP: Virtual Instance Port, : Trunk Instance Port, : Link Instance Port 19 P -VLN scalability arch 2007