This model defines parameters and constraints that can influence the meshing of the site-network-access. The management system MUST honor all customer constraints, or, if a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and MUST provide the user with information regarding any constraints that could not be fulfilled. How this information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user. Parameters such as site location (see Section 5.6.2) and access type (see Section 5.6.3) affect the service placement that the management system applies. In addition to parameters and constraints, the management system's decision MAY be based on any other internal constraints that are left up to the SP, e.g., least load, distance. New York Site +------------------+ Site | +--------------+ |------------------------------------- | | Manhattan | | | | CE1********* (site-network-access#1) ****** | +--------------+ | | +--------------+ | | | Brooklyn | | | | CE2********* (site-network-access#2) ****** | +--------------+ | | |------------------------------------- +------------------+ Figure 18: Example of a Constraint Applied to a Device In Figure 18, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.
RFC4119]. The site-network-access location is determined by the "location-flavor". In the case of a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device that the customer ordered. As each device is already associated with a particular location, in such a case the location information is retrieved from the device location. In the case of a customer-managed site, the user is expected to configure a "location-reference" (location case); this provides a reference to an existing configured location and will help with placement. POP#1 (New York) +---------+ | PE1 | Site 1 ---... | PE2 | (Atlantic City) | PE3 | +---------+ POP#2 (Washington) +---------+ | PE4 | | PE5 | | PE6 | +---------+ POP#3 (Philadelphia) +---------+ | PE7 | Site 2 CE#1---... | PE8 | (Reston) | PE9 | +---------+ Figure 19: Location Information for Sites In Figure 19, Site 1 is a customer-managed site with a location "L1", while Site 2 is a provider-managed site for which a CE (CE#1) was ordered. Site 2 is configured with "L2" as its location. When
configuring a site-network-access for Site 1, the user will need to reference location L1 so that the management system will know that the access will need to terminate on this location. Then, for distance reasons, this management system may mesh Site 1 on a PE in the Philadelphia POP. It may also take into account resources available on PEs to determine the exact target PE (e.g., least loaded). For Site 2, the user is expected to configure the site-network-access with a device-reference to CE#1 so that the management system will know that the access must terminate on the location of CE#1 and must be connected to CE#1. For placement of the SP side of the access connection, in the case of the nearest PE used, it may mesh Site 2 on the Washington POP.
Any other internal parameters from the SP can also be used. The management system MAY use other parameters, such as the requested "input svc-bandwidth" and "output svc-bandwidth", to help decide which access type to use.
o pop-diverse: The current site-network-access MUST NOT be connected to the same POP as the targeted site-network-accesses. o linecard-diverse: The current site-network-access MUST NOT be connected to the same linecard as the targeted site-network- accesses. Note that the customer can request linecard-diverse for site-network-accesses, but the specific linecard identifier used should not be exposed to the customer. o bearer-diverse: The current site-network-access MUST NOT use common bearer components compared to bearers used by the targeted site-network-accesses. "bearer-diverse" provides some level of diversity at the access level. As an example, two bearer-diverse site-network-accesses must not use the same Digital Subscriber Line Access Multiplexer (DSLAM), Broadband Access Switch (BAS), or Layer 2 switch. o same-pe: The current site-network-access MUST be connected to the same PE as the targeted site-network-accesses. o same-bearer: The current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses. These constraint-types can be extended through augmentation. Each constraint is expressed as "The site-network-access S must be <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target> site-network-accesses." The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access. This eases the configuration of scenarios where a group of site-network-access points has a constraint between the access points in the group. RFC4364] that provides the ability to distinguish common addressing plans in different VPNs. As for Route Targets (RTs), a management system is expected to allocate a MAC-VRF on the target PE and an RD for that MAC-VRF; that RD MUST be unique across all MAC-VRFs on the target PE. If a MAC-VRF already exists on the target PE and the MAC-VRF fulfills the connectivity constraints for the site, there is no need to recreate another MAC-VRF, and the site MAY be meshed within the existing MAC-VRF. How the management system checks to see if an existing MAC-VRF fulfills the connectivity constraints for a site is out of scope for this document.
If no such MAC-VRF exists on the target PE, the management system has to initiate the creation of a new MAC-VRF on the target PE and has to allocate a new RD for the new MAC-VRF. The management system MAY apply a per-VPN or per-MAC-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all MAC-VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-MAC-VRF model, all MAC-VRFs should always have a unique RD value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used. The allocation of RDs MAY be done in the same way as RTs. The information provided in Section 220.127.116.11 could also be used in this scenario. Note that an SP MAY configure a target PE for an automated allocation of RDs. In this case, there will be no need for any backend system to allocate an RD value. Section 5.6 will help ensure physical diversity. When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses. The "site-network-access/availability" container defines parameters for site redundancy. The "access-priority" leaf defines a preference for a particular access. This preference is used to model load-balancing or primary/backup scenarios. The higher the access-priority value, the higher the preference will be. The "redundancy-mode" attribute is defined for a multihoming site and used to model single-active and active/active scenarios. It allows for multiple active paths in forwarding state and for load-balancing options.
Figure 20 illustrates how the access-priority attribute can be used. Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing) | | | access-priority 1 access-priority 1 | |--- CE1 ------- PE1 PE3 --------- CE3 --- | | | | | |--- CE2 ------- PE2 PE4 --------- CE4 --- | | access-priority 2 access-priority 1 | PE5 | | | CE5 | Spoke#1 site (Single-homed) Figure 20: Example: Configuring Access Priority In Figure 20, Hub#2 requires load-sharing, so all the site-network- accesses must use the same access-priority value. On the other hand, as Hub#1 requires a primary site-network-access and a backup site-network-access, a higher access-priority setting will be configured on the primary site-network-access. Scenarios that are more complex can also be modeled. Let's consider a Hub site with five accesses to the network (A1, A2, A3, A4, and A5). The customer wants to load-share its traffic on A1 and A2 in the nominal situation. If A1 and A2 fail, the customer wants to load-share its traffic on A3 and A4; finally, if A1, A2, A3, and A4 are all down, the customer wants to use A5. We can model this easily by configuring the following access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10. The access-priority scenario has some limitations. An access-priority scenario like the previous one with five accesses but with the constraint of having traffic load-shared between A3 and A4 in the case where only A1 or A2 (not both) is down is not achievable. But the access-priority attribute defined will cover most of the deployment use cases, and if necessary the model can be extended via augmentation to support additional use cases.
The svc-bandwidth parameter must include a "cos-id" parameter if the "type" is set to "bw-per-cos". The cos-id can be assigned based on either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or (2) the Differentiated Services Code Point (DSCP) in the Ethernet frame header. Service frames are metered against the bandwidth profile based on the cos-id. The svc-bandwidth parameter must be associated with a specific "site-network-access-id" parameter if the "type" is set to "bw-per-access". Multiple bandwidths per cos-id can be associated with the same site network access. The svc-bandwidth parameter must include a specific "vpn-id" parameter if the "type" is set to "bw-per-svc". Multiple bandwidths per cos-id can be associated with the same EVPN service.
"target-sites" leaf-list and "vpn-attachment" to identify the destination of a flow targeted to a specific VPN service. A rule that does not have a "match" statement is considered a "match-all" rule. An SP may implement a default terminal classification rule if the customer does not provide it. It will be up to the SP to determine its default target class. This model defines some applications, but new application identities may be added through augmentation. The exact meaning of each application identity is up to the SP, so it will be necessary for the SP to advise the customer on the usage of application-matching.
o frame-jitter: Used to define the jitter constraint of the class. The jitter constraint can be expressed as the lowest possible jitter or as a jitter boundary expressed in microseconds. How this jitter constraint will be fulfilled is up to the SP implementation: a strict priority-queuing mechanism may be used on the access and in the core network, or a jitter-aware routing path may be created for this traffic class. o bandwidth: Used to define a guaranteed amount of bandwidth for the CoS. It is expressed as a percentage. The "guaranteed-bw-percent" parameter uses available bandwidth as a reference. The available bandwidth should not fall below the CIR value defined under the input svc-bandwidth or the output svc-bandwidth. When the "qos-profile" container is implemented on the CE side, the output svc-bandwidth is taken into account as a reference. When it is implemented on the PE side, the input svc-bandwidth is used. By default, the bandwidth reservation is only guaranteed at the access level. The user can use the "end-to-end" leaf to request an end-to-end bandwidth reservation, including across the MPLS transport network. (In other words, the SP will activate something in the MPLS core to ensure that the bandwidth request from the customer will be fulfilled by the MPLS core as well.) How this is done (e.g., RSVP-TE reservation, controller reservation) is out of scope for this document. In addition, due to network conditions, some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations. How this communication is done is out of scope for this document.
For point-to-point services, the provider only needs to deliver a single copy of each service frame to the remote PE, regardless of whether the destination MAC address of the incoming frame is unicast, multicast, or broadcast. Therefore, all service frames should be delivered unconditionally. BUM frame forwarding in multipoint-to-multipoint services, on the other hand, involves both local flooding to other ACs on the same PE and remote replication to all other PEs, thus consuming additional resources and core bandwidth. Special BUM frame disposition rules can be implemented at external-facing interfaces (UNIs or External NNIs (E-NNIs)) to rate-limit the BUM frames, in terms of the number of packets per second or bits per second. The threshold can apply to all BUM traffic, or one threshold can be applied for each category of traffic.