Service access points (SAPs)

Topics in this section include:

A service access point (SAP) is the point at which a service begins (ingress) or ends (egress) and represents the access point associated with a service. A SAP may be a physical port or a logical entity within a physical port. For example, a SAP may be an Ethernet port or a VLAN that is identified by an Ethernet port and a VLAN tag. Each application service connection is configured to use only one SAP.

A SAP identifies the application interface point for a service on a service router. Service access point (SAP) shows two applications connected to the same service via two different SAPs. The SAP identifiers are 1/2/5 and 1/2/6, which represent the physical ports associated with these SAPs. The physical port information should be configured before provisioning a service. For more information about configuring a port, see the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide.

The 7705 SAR-Hm series supports VLL, VPWS, VPLS, and VPRN services. For each service type, the SAP has slightly different parameters; see Layer 2 and Layer 3 services for information.

In general, SAPs are logical endpoints that are local to the node and are uniquely identified by:

  • the physical Ethernet port

  • the physical serial port

  • the encapsulation type for the service

  • the encapsulation identifier (ID), which is the optional VLAN ID for Epipes

Depending on the encapsulation, a physical port can have more than one SAP associated with it (for example, a port may have several VLANs, where each VLAN has an associated SAP). SAPs can only be created on ports designated as "access" in the physical port configuration.

SAPs cannot be created on ports designated as core-facing "network" ports because these ports have a different set of features enabled in software.

Figure 1. Service access point (SAP)

SAP encapsulation types and identifiers

The SAP encapsulation type is an access property of the Ethernet port used for the service. It identifies the protocol that is used to provide the service.

The encapsulation ID for Ethernet ports is an optional suffix that is appended to a port-id to specify a logical sub-element for a SAP. For example, port-id:qtag1 represents a port that can be tagged to use IEEE 802.1Q encapsulation (referred to as dot1q), where each individual tag can identify with an individual service.

Ethernet encapsulations

The following encapsulation service options are available on Ethernet ports:

  • null—supports a single service on the port; for example, where a single customer with a single service customer edge (CE) device is attached to the port.

  • dot1q—supports multiple services for one customer or services for multiple customers (see Multiple SAPs on a single port). For example, dot1q could be used when the Ethernet port is connected to a multi-tenant unit device with multiple downstream customers. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.

Figure 2. Multiple SAPs on a single port

Default SAP on a dot1q port

The 7705 SAR-Hm series of routers supports default SAP functionality on dot1q- encapsulated ports. On dot1q-encapsulated ports where a default SAP is configured, all packets with Q-tags not matching any other explicitly defined SAPs are assigned to the default SAP for transport. A default SAP is defined in the CLI using the character "*" as a Q-tag, where the "*" means "all".

One of the applications where the default SAP feature can be used is for an access connection of an application that uses the whole port to access Layer 2 services. The internal VLAN tags are transparent to the service. This (the use of a whole port) can be provided by a null-encapsulated port. A dedicated VLAN (not used by the user) can be used to provide management to this application.

In this type of environment, two SAPs logically exist, a management SAP and a service SAP. The management SAP can be created by specifying a VLAN tag that is reserved to manage the application. The service SAP covers all other VLANs and behaves as a SAP on a null-encapsulated port.

There are a few constraints related to the use of a default SAP on a dot1q-encapsulated port:

  • The default SAP is supported only on VPLS, and Epipe VLL and VPWS services and cannot be created in IES and VPRN services because IES and VPRN services cannot preserve VLAN tag markings.

  • For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.

  • IGMP snooping is not supported on a default SAP. By not allowing IGMP snooping of a default SAP, all IGMP packets will be transparently forwarded.

  • The default SAP and the SAP defined by explicit null encapsulation are mutually exclusive (for example, 1/1/1:* and 1/1/1:0 are mutually exclusive). This avoids conflict as to which SAP untagged frames should be associated with.

SAP configuration considerations

In addition to being an entry or exit point for service traffic, a SAP has to be configured for a service and, therefore, has properties. When configuring a SAP, consider the following.

  • A SAP is a local entity and is only locally unique to a specific device. The same SAP ID value can be used on another service router.

  • There are no default SAPs. All subscriber service SAPs must be created.

  • The default administrative state for a SAP at creation time is administratively enabled.

  • When a SAP is deleted, all configuration parameters for the SAP are also deleted.

  • A SAP is owned by and associated with the service in which it is created.

  • An Ethernet port with a dot1q encapsulation type means that the traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID is placed on at SAP egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the SAPs for a service need not be the same at each SAP.

  • If a port is administratively shut down, all SAPs on that port will be operationally out of service.

  • A SAP cannot be deleted until it has been administratively disabled (shut down).

  • Each SAP can have one of the following policies assigned to it:

    • Ingress QoS policy

    • Egress QoS policy

    • Ingress filter policy (for Epipe VLL and VPWS SAPs, VPLS SAPs, VPRN SAPs, IES SAPs, and IES in-band management SAPs)

    • Egress filter policy (for VPRN and IES SAPs, and for VPLS SAPs (Ethernet SAPs only))