Service Attributes Overview

Service Type

The Service type attribute specifies a network topology to include in the service definition.

The service type is the first attribute to be determined during service definition. It can be one of the following values:

• E-Line—Virtual circuit between two customer sites in the network core.

• E-LAN (Multipoint-to-multipoint) —Virtual private LAN service (VPLS) among multiple customer sites in the network core to provide full mesh connectivity.

• E-LAN (Point-to-multipoint) —VPLS among multiple customer sites in the network core to provide connectivity between a hub site and multiple spoke sites.

• IP —Supports full mesh and hub-spoke connectivity through different routing protocols such as BGP, OSPF, or static protocols, or a combination of these.

Signaling

The Signaling attribute specifies the protocol that controls signaling in the network core. You can select BGP or LDP.

Comments

The Comments attribute .

Service Template

The Service Template attribute .

Threshold Alarm Profile

The Threshold Alarm Profile attribute.

Interface Type

The Interface type attribute . You can specify one of the following:

• Ethernet

• TDM

• ATM

Enabling Additional Features

In addition to the interface type, depending on the Service type topology and Signaling you specify, you can enable the following features for a service:

• Static pseudowire—For networks that do not support LDP or do not have LDP enabled. You define pseudowires by configuring static values for the inbound and outbound labels of the connection.

• Enable PW access to L3 VPN networks

• Enable L3 Access

• Enable Multihoming

• Enable PW Extension

• Enable PW Resiliency

• Decouple Service Status from Port Status—Isolates events related to an interface in the OpenNMS database. Only traps related to pseudowires are monitored.

Customer

This attribute specifies the enterprise customer who will use the service instance. This attribute is always specified in the service order.

Enable QoS

This attribute specifies whether QoS is enabled on the service to divide traffic into classes and offer various levels of throughput and packet loss when congestion occurs. When you enable QoS in the service definition, the QoS Settings box appears when you configure the service order.

Ethernet Options

This attribute identifies the interface type at the endpoint by defining the level of packet tagging for the UNI. It can have the following values:

• asymmetric tag depth

  Allows port-based, 802.1Q and Q-in-Q interfaces for UNIs to coexist in a service.

• port-port

  Transfers all data from the UNI to the other end of the LSP trunk.

• dot1q

  An 802.1Q interface that tags each packet with a VLAN ID, thus allowing a specific VLAN to traverse the network.

• qinq

  A Q-in-Q interface that double tags each frame. The inner tag is added by the service provider. The service provider can use this inner tag to differentiate among services. For example, you can configure VLANs for a customer’s intranet with a different inner tag from VLANs used for working with providers or partners.

Interface

Specifies the physical interface on the N-PE device that connects the customer site or CE device to the N-PE device.

MTU

The maximum transmission unit (MTU) represents the largest frame size, in bytes, that passes through the UNI. MTU is configurable.

Customer Traffic Type

This attribute places restrictions on the traffic that can be transported across the network by the associated service. It can have the following values:

• Transport single VLAN

  Restricts the associated service to transporting just one VLAN across the network. You can use this option with 802.1Q and Q-in-Q interface types.

• Transport VLAN range

  Allows the associated service to transport a range of VLANs across the network. You can use this option with 802.1Q and Q-in-Q interface types.

• Transport all traffic

  Allows the associated service to transport all traffic across the network. You can use this option with Q-in-Q interface types only.

  The traffic type attribute is not applicable to port-to-port services. Port-to-port services always transport all traffic.

• Transport VLAN list

  Allows the associated service to transport a list of VLANs across the network. You can use this option with dot1q, qinq, and asymmetric tag depth VLAN tagging types.

Customer VLAN ID

Specifies a VLAN ID that is attached to each packet to permit VLANs to be shared across the network.

This attribute can be used only with 802.1Q and Q-in-Q interface types.

Service VLAN ID and VLAN ID Range

The service VLAN ID (VLAN ID) specifies a second level of tagging to segregate groups of VLANs.

The VLAN range specifies a range of VLANs to be transported across the network by associating them with a service VLAN ID.

These options are configurable only for Q-in-Q interfaces.

Physical Encapsulation

Specifies the physical link-layer encapsulation type.

• flexible-ethernet-services—Offers the most flexibility, depending on the characteristics of the N-PE device and its line modules.

  For Gigabit Ethernet IQ interfaces and Gigabit Ethernet PICs with small form-factor pluggable transceivers (SFPs) only, use flexible Ethernet services encapsulation when you want to configure multiple per-unit Ethernet encapsulations. This encapsulation type allows you to configure any combination of route, TCC, CCC, and VPLS encapsulations on a single physical port. Aggregated Ethernet bundles cannot use this encapsulation type. If you configure flexible Ethernet services encapsulation on the physical interface, VLAN IDs from 1 through 511 are no longer reserved for normal VLANs.

  In the Junos Space Connectivity Services Director product, you can use this encapsulation type with 802.1Q interfaces and Q-in-Q interfaces in E-Line services and in multipoint Ethernet services.

• vlan-ccc—You can use Ethernet VLAN encapsulation on CCC interfaces. This option restricts the range of available VLAN IDs to 512 through 4094. VLAN IDs 1 through 511 are reserved for internal use.

  In the Junos Space Connectivity Services Director product, you can use this encapsulation type with 802.1Q interfaces and Q-in-Q interfaces in E-Line services.

• extended-vlan-ccc—Use extended VLAN encapsulation on CCC interfaces with Gigabit Ethernet interfaces that must accept packets carrying 802.1Q values.

  In the Junos Space Connectivity Services Director product, you can use this encapsulation type with 802.1Q interfaces and Q-in-Q interfaces in E-Line services.

• ethernet-vpls—Use Ethernet VPLS encapsulation on Ethernet interfaces that have VPLS enabled and that must accept packets carrying standard TPID values.

  In the Junos Space Connectivity Services Director product, this encapsulation is used only for dedicated port interface types in multipoint Ethernet services.

Logical Encapsulation

Specifies the logical link-layer encapsulation type. Logical encapsulation with 802.1Q interfaces allows you to route multiple services through the same physical interface.

• vlan-ccc—Use Ethernet virtual LAN (VLAN) encapsulation on CCC interfaces. When you use this encapsulation type, you can configure the family ccc only.

• extended-vlan-ccc—Use extended VLAN encapsulation on CCC interfaces with Gigabit Ethernet interfaces that must accept packets carrying 802.1Q values.

• vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN tagging and VPLS enabled. Interfaces with VLAN VPLS encapsulation accept packets carrying standard Tag Protocol (TPID) values only.

Table 1 defines the logical encapsulation types that are valid for each physical encapsulation type in an E-Line service.

Table 2 defines the logical encapsulation types that are valid for each physical encapsulation type in multipoint Ethernet services.

Rate Limiting and Bandwidth

Rate limiting allows you to specify the maximum bandwidth permitted for a service.

The burst rate is automatically calculated as two times the MTU of the UNI.

UNI Settings for TDM Interfaces

The following TDM options are configurable for TDM interfaces:

• Physical IF encapsulation—satop or cesopsn

• Jitter buffer

  M Series: 1 through 340

• Idle pattern—0 through 255

• Excessive packet loss rate—1 through 100%

• Payload size

  M Series: 64 through 1024

UNI Settings for ATM Interfaces

The following ATM options are configurable for ATM interfaces:

• Physical IF encapsulation—The type of encapsulation to apply to the interface. Use atm-ccc-cell-relay for ATM cell relay encapsulation. Use atm-ccc-cell-mux for ATM VC for CCC.

• VPI selection—The virtual path identifier

• VCI selection—This integer uniquely identifies the virtual circuit that the service uses.

• Cell bundle size—Cell bundle size can be 1 through 34.

Virtual Private LAN Service Identifier (VPLS ID)

This VPLS ID is available if the signaling is LDP and the Auto Discovery check box is disabled. The VPLS ID can be selected automatically or manually. The VPLS ID identifies the virtual circuit identifier used for the VPLS routing instance.

Auto Discovery

The Auto Discovery check box is available only if the signaling is LDP. If you enable Auto Discovery, the attributes Route target, Route distinguisher, and VPN ID appear and are provisionable.

Virtual Circuit Identifier (VCID) (E-Line Services Only)

This unique identifier can be assigned automatically from a pool of VCIDs or can be manually specified. It uniquely identifies a point-to-point virtual circuit through the network and is provided for all switched E-Line services.

Route Targets and Route Distinguishers

Route targets and route distinguishers are applied to E-Line services in which BGP controls the connections in the network core.

Route targets and route distinguishers are always automatically generated by the Junos Space software for multipoint E-LAN services. Route targets and route distinguishers designate the multipoint connectivity among the participating endpoints of a multipoint service. They identify the members of the virtual LAN.

Normalized VLAN (Multipoint Services Only)

Similar to E-Line services, the UNIs of E-LAN services can be port-to-port, 802.1Q, or Q-in-Q. The type of VLAN mapping—or normalization—is specified in the service definition. VLAN normalization applies only to MX Series devices.

Normalization supports automatic mapping of VLANs and performs operations on VLAN tags to achieve the desired translation. The Connectivity Services Director application supports the following forms of VLAN normalization:

• Normalize to VLAN all—The customer VLAN ID is preserved across the network. That is, the broadcast domain includes the interfaces that have the same VLAN ID across the E-LAN service. For double-tagged packets (Q-in-Q interfaces), a pop operation at ingress strips the service VLAN ID from the packet. A corresponding push operation at egress inserts the service VLAN ID known at the local site. Hence, the service VLAN ID at egress does not have to match the service VLAN ID at ingress.

  For single-tagged packets (802.1Q interfaces), “Normalize to VLAN All” has no effect, because the packet has no service VLAN ID to pop or push.

• Normalize to VLAN none—The customer VLAN ID is not preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For single-tagged packets (802.1Q interfaces), a pop operation at ingress removes the customer VLAN ID from the packet. A corresponding push operation at egress adds a local customer VLAN ID.

  For double-tagged packets (Q-in-Q interfaces), both customer VLAN ID and service VLAN ID are popped from the packet at ingress and pushed at egress.

• Normalize to Dot1q tag— The VLAN tag is preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For information about how frames are translated to provide the required VLAN tags for interfaces with different tag heights, see the section “VLAN Mapping for E-LAN Services” in Understanding VLAN Manipulation (Normalization and VLAN Mapping) on Ethernet Services.

• Normalize to QinQ tags—The inner VLAN tag and outer VLAN tag are preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For information about how frames are translated to provide the required VLAN tags for interfaces with different tag heights, see the section “VLAN Mapping for E-LAN Services” in Understanding VLAN Manipulation (Normalization and VLAN Mapping) on Ethernet Services.

• Normalization not required—For port-to-port services only. Specifies that normalization is not used.

If normalization is not used, then all customer VLAN IDs and all service VLAN IDs must match to be part of the same broadcast domain. Services with dedicated port interfaces cannot use normalization.

Normalization works well with automatically assigned VLAN IDs, because the service provider does not need to specify the VLAN IDs that are popped and pushed. Without normalization, the service provider must specify explicitly the customer VLAN ID and the service VLAN ID.

MAC Learning

You can enable MAC learning for a virtual switch, for a bridge domain, for a specific logical interface in a bridge domain, or for a set of bridge domains associated with a Layer 2 trunk port. MAC learning is enabled by default.

When MAC learning is enabled, you can configure the following settings:

Tunnel Services

You can enable tunnel services to specify that traffic for particular VPLS routing instances be forwarded to specific virtual tunnel (VT) interfaces, allowing you to load-balance VPLS traffic among all the available VT interfaces on the router.

Tunnel services are disabled by default.

Local Switching

In local switching mode, you can terminate multiple Layer 2 circuit pseudowires at a single VPLS mesh group.

Local switching is disabled by default.

Fast Reroute Priority

Specify the fast reroute priority for a VPLS routing instance. You can configure high, medium, or low fast reroute priority to prioritize specific VPLS routing instances for faster convergence and traffic restoration. Because the router repairs next hops for high-priority VPLS routing instances first, the traffic traversing a VPLS routing instance configured with high fast reroute priority is restored faster than the traffic for VPLS routing instances configured with medium or low fast reroute priority. The default setting is LOW.

Label Block Size

VPLS MPLS packets have a two-label stack. The outer label is used for normal MPLS forwarding in the service provider’s network. If BGP is used to establish VPLS, the inner label is allocated by a PE router as part of a label block. One inner label is needed for each remote VPLS site. Four sizes are supported. We recommend using the default size of 8, unless the network design requires a different size for optimal label usage, to allow the router to support a larger number of VPLS instances.

If you allocate a large number of small label blocks to increase efficiency, you also increase the number of routes in the VPLS domain. This has an impact on the control plane overhead.

Changing the configured label block size causes all existing pseudowires to be deleted. For example, if you configure the label block size to be 4 and then change the size to 8, all existing label blocks of size 4 are deleted, which means that all existing pseudowires are deleted. The new label block of size 8 is created, and new pseudowires are established.

Four label block sizes are supported: 2, 4, 8, and 16. Consider the following scenarios:

• 2—Allocate the label blocks in increments of 2. For a VPLS domain that has only two sites with no future expansion plans.

• 4—Allocate the label blocks in increments of 4.

• 8 (default)—Allocate the label blocks in increments of 8.

• 16—Allocate the label blocks in increments of 16. A label block size of 16 enables you to minimize the number of routes in the VPLS domain. Use this setting only if the number of routes is the most important concern.

Connectivity Type

You can configure the VPLS routing instance to take down or maintain its VPLS connections depending on the status of the interfaces configured for the VPLS routing instance. By default, the VPLS connection is taken down whenever a customer-facing interface configured for the VPLS routing instance fails. This behavior is explicitly configured by specifying the ce option. You can alternatively specify the irb option to ensure that the VPLS connection remain up so long as an integrated routing and bridging (IRB) interface is configured for the VPLS routing instance.

Static Routes

Routes that are permanent fixtures in the routing and forwarding tables are often configured as static routes. These routes generally do not change, and often include only one or very few paths to the destination. To create a static route in the routing table, you must, at minimum, define the route as static and associate a next-hop address with it. The static route in the routing table is inserted into the forwarding table when the next-hop address is reachable. All traffic destined for the static route is transmitted to the next-hop address for transit. You can specify options that define additional information about static routes that is included with the route when it is installed in the routing table. All static options are optional. A router uses static routes in the following scenarios:

When it does not have a route to a destination that has a better (lower) preference value.

When it cannot determine the route to a destination.

When it is forwarding unroutable packets.

For the destination prefix of the static route, you must specify the destination of the route (in route destination-prefix) in one of the following ways:

network/mask-length, where network is the network portion of the IP address and mask-length is the destination prefix length.

default if this is the default route to the destination. This is equivalent to specifying an IP address of 0.0.0.0/0.

For the next-hop portion of the static route, you must configure the IPv4, IPv6, or ISO network address of the next hop or the name of the interface on which to configure an independent metric or preference for a static route.

PIM Settings

Protocol Independent Multicast (PIM) emerged as an algorithm to overcome the limitations of dense-mode protocols such as the Distance Vector Multicast Routing Protocol (DVMRP), which was efficient for dense clusters of multicast receivers, but did not scale well for the larger, sparser, groups encountered on the Internet. The Core Based Trees (CBT) Protocol was intended to support sparse mode as well, but CBT, with its all-powerful core approach, made placement of the core critical, and large conference-type applications (many-to-many) resulted in bottlenecks in the core. PIM was designed to avoid the dense-mode scaling issues of DVMRP and the potential performance issues of CBT at the same time. PIM operates in several modes: bidirectional mode, sparse mode, dense mode, and sparse-dense mode. In sparse-dense mode, some multicast groups are configured as dense mode (flood-and-prune, [S,G] state) and others are configured as sparse mode (explicit join to rendezvous point [RP], [*,G] state). To join the shared tree, or rendezvous-point tree (RPT) as it is called in PIM sparse mode, the router must do the following: Determine the IP address of the RP for that group. Determining the address can be as simple as static configuration in the router, or as complex as a set of nested protocols.

• Build the shared tree for that group. The router executes an RPF check on the RP address in its routing table, which produces the interface closest to the RP. The router now detects that multicast packets from this RP for this group need to flow into the router on this RPF interface.

• Send a join message out on this interface using the proper multicast protocol (probably PIM sparse mode) to inform the upstream router that it wants to join the shared tree for that group. This message is a (*,G) join message because S is not known. Only the RP is known, and the RP is not actually the source of the multicast packets. The router receiving the (*,G) join message adds the interface on which the message was received to its outgoing interface list (OIL) for the group and also performs an RPF check on the RP address. The upstream router then sends a (*,G) join message out from the RPF interface toward the source, informing the upstream router that it also wants to join the group.

You can specify the following attributes: PIM mode on the interface. The choice of PIM mode is closely tied to controlling how groups are mapped to PIM modes, as follows: bidirectional-sparse—Use if all multicast groups are operating in bidirectional, sparse, or SSM mode. bidirectional-sparse-dense—Use if multicast groups, except those that are specified in the dense-groups statement, are operating in bidirectional, sparse, or SSM mode. dense—Use if all multicast groups are operating in dense mode. sparse—Use if all multicast groups are operating in sparse mode or SSM mode. sparse-dense—Use if multicast groups, except those that are specified in the dense-groups statement, are operating in sparse mode or SSM mode

Name of the interface on which PIM must be enabled. Specify the full interface name, including the physical and logical address components.

Configure the routing device as an actual or potential rendezvous point (RP). A routing device can be an RP for more than one group.

Name of the interface on the device that functions as the RP.

Address ranges for the multicast groups for which the routing device is the RP. By default, a routing device running PIM is eligible to be the RP for all IPv4 or IPv6 groups (224.0.0.0/4 or FF70::/12 to FFF0::/12). The following example limits the groups for which this routing device can be the RP.

MVPN Settings

Multiprotocol BGP-based multicast VPNs (also referred to as next-generation Layer 3 VPN multicast) constitute the next evolution after dual multicast VPNs (draft-rosen) and provide a simpler solution for administrators who want to configure multicast over Layer 3 VPNs. For MBGP MVPNs (also referred to as next-generation Layer 3 multicast VPNs), the default mode of operation supports only intersite shortest-path trees (SPTs) for customer PIM (C-PIM) join messages. It does not support rendezvous-point trees (RPTs) for C-PIM join messages. The default mode of operation provides advantages, but it requires either that the customer rendezvous point (C-RP) be located on a PE router or that the Multicast Source Discovery Protocol (MSDP) be used between the C-RP and a PE router so that the PE router can learn about active sources advertised by other PE routers. If the default mode is not suitable for your environment, you can configure RPT-SPT mode (also known as shared-tree data distribution), as documented in section 13 of the BGP-MVPN draft (draft-ietf-l3vpn-2547bis-mcast-bgp-00.txt). RPT-SPT mode supports the native PIM model of transmitting (*,G) messages from the receiver to the RP for intersite shared-tree join messages. This means that the type 6 (*,G) routes get transmitted from one PE router to another. In RPT-SPT mode, the shared-tree multicast routes are advertised from an egress PE router to the upstream router connected to the VPN site with the C-RP. The single-forwarder election is performed for the C-RP rather than for the source. The egress PE router takes the upstream hop to advertise the (*,G) and sends the type 6 route toward the upstream PE router. To send the data on the RPT, either inclusive or selective provider tunnels can be used. After the data starts flowing on the RPT, the last-hop router switches to SPT mode, unless you include the spt-threshold infinity statements in the configuration.

You can specify the following parameters:

• Indicate whether the shared-tree data distribution mode or the shortest path tree only (SPT-only) mode of MVPN must be enabled to learn about active multicast sources using multicast VPN source-active routes. the default mode of operation is shortest path tree only (SPT-only) mode. In SPT-only mode, the active multicast sources are learned through multicast VPN source-active routes. This mode of operation is described in section 14 of the BGP-MVPN draft (draft-ietf-l3vpn-2547bis-mcast-bgp-00.txt).

• Specify the export and import targets specified specifically for sender sites or receiver sites, or can be borrowed from a configured unicast route target. Note that a sender site export route target is always advertised when security association routes are exported. By default, the VPN routing and forwarding (VRF) import and export route targets (configured either using VRF import and export policies or using the vrf-target statement) are used for importing and exporting routes with the MBGP MVPN network layer reachability information (NLRI). You can use the export-target and import-target options to override the default VRF import and export route targets.

• Specify the export target to enable you to override the Layer 3 VPN import and export route targets used for importing and exporting routes for the MBGP MVPN network layer reachability information (NLRI).

• Specify the target value when importing sender and receiver site routes.

• Specify a unicast target community as the import target while importing sender and receiver site routes.

• Specify if you want to enable automatic selection of an export targert if a configuration is not provided. An imported automatic discovery route is treated as belonging to both the sender site set and the receiver site set.

• Specify the export and import target community names.

• Specify the provider tunnel name to configure virtual private LAN service (VPLS) flooding of unknown unicast, broadcast, and multicast traffic using point-to-multipoint LSPs. Also configure point-to-multipoint LSPs for MBGP MVPNs.

• Specify the site type of the MBGP MVPN. An MBGP MVPN defines two types of site sets, a sender site set and a receiver.

• Configure the upstream multicast hop (UMH) to denote a router to use the unicast route preference to determine the single forwarder election.

MAC Settings

You can specify the following attributes related to the MAC application of a node:

Enable or disable MAC learning for all logical interfaces in a specified bridge domain, or for a specific logical interface in a bridge domain. Disabling dynamic MAC learning prevents the specified interfaces from learning source MAC addresses. A limit on the number of MAC addresses learned from a specific bridge domain or from a specific logical interface that belongs to a bridge domain. For an access port, the default limit on the maximum number of MAC addresses that can be learned on an access port is 1024. For a trunk port, the default limit on the maximum number of MAC addresses that can be learned on a trunk port is 8192.

Enable or disable packet accounting either for a router or switch as a whole or for a specific VLAN. After you enable packet accounting, the Junos OS maintains packet counters for each MAC address learned. By default, MAC accounting is disabled. Size of the MAC address table for each VLAN. The default table size is 5120 addresses. The minimum you can configure is 16 addresses, and the maximum is 1,048,575 addresses. If the MAC table limit is reached, new addresses can no longer be added to the table. Unused MAC addresses are removed from the MAC address table automatically. This frees space in the table, allowing new entries to be added.

Topology Settings

Automatically assign a route distinguisher to the routing instance. Alternatively, specify the route distinguisher manually by specifying an identifier attached to a route, enabling you to distinguish to which VPN or VPLS the route belongs. Each routing instance must have a unique route distinguisher associated with it. The route distinguisher is used to place bounds around a VPN so that the same IP address prefixes can be used in different VPNs without having them overlap.