8. Services Overview
Topics in this chapter include:
8.1. Overview
A service is a type of communication connection from one place to another. These communication connections have particular attributes and characteristics that are needed to provide a specific communications link through which an information flow or exchange can occur. The 7705 SAR-Hm series of routers support the following services:
- Layer 2 Virtual Leased Line (VLL) and BGP virtual private wire services (VPWS)
- Layer 2 virtual private LAN services (VPLS) and BGP VPLS services
- Layer 3 IP VPN services (VPRN)
- serial transport using raw socket and IP transport services
- transporting WLAN interface traffic over a service
The service model uses (logical) service entities to construct a service. These logical entities provide a uniform, service-centric configuration and management model for service provisioning (see Nokia Service Model for more information). Different services can be created on the same node at the same time, and each service is uniquely identified by a service ID.
The supported services provide connectivity between a service access point (SAP) on one node and a SAP on a remote node. A SAP is a logical point where data traffic enters and exits a service. SAPs on the node are associated with Ethernet ports, VLANs, access router interfaces, serial ports, or the WLAN interface.
A connection between two SAPs on the same router is known as a local service. A connection between SAPs on a local and a remote router is known as a distributed service. SAP-to-SAP local services are supported for Ethernet and WLAN-based services. SAP-to-SAP local services are not supported for serial port and raw socket IP transport services.
Distributed services use service destination points (SDPs) to direct traffic from a local router to a remote router through a service tunnel. An SDP is created on the local router and identifies the endpoint of a logical unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Hence, a service tunnel provides a path from one service router to another. Because an SDP is unidirectional, two service tunnels are needed for bidirectional communication between two service routers (one SDP on each router). The only supported SDP tunnel type is GRE-MPLS tunnels.
SDPs are configured on each participating service router or are auto-bound to the far-end router depending on the requirements and type of service. When configuring SDPs on the source router, the address of the destination router must be specified. When using the auto-bind function for SDPs, configuring individual SDPs between service routers is not required. The node uses BGP-advertised information to perform the auto-bind SDP function to the far-end routers. For more information on auto-bind, see SDP Binding.
After SDPs are created, they are bound to a specific service, or the service is enabled with auto-bind SDPs, to create a binding to the transport tunnels. In both cases, the SAPs that are part of the service use the bound SDPs as the transport for data traffic between nodes. The binding process is needed to associate the far-end devices to the service; otherwise, far-end devices are not able to participate in the service.
8.2. Service Types
The 7705 SAR-Hm series of routers offers the following types of services:
- Virtual Leased Line (VLL) services
- Ethernet VLL (Epipe)—a PWE3 Ethernet service over MPLS or GRE tunnels for Ethernet frames on 7705 SAR-Hm nodes.
- BGP Virtual Private Wire Services (VPWS)
- BGP VPWS is a point-to-point Layer 2 VPN service based on RFC 6624 (Layer 2 Virtual Private Networks using BGP for Auto-Discovery and Signaling) which in turn uses the BGP pseudowire signaling concepts from RFC 4761, Virtual Private LAN Services Using BGP for Auto-Discovery and Signaling.
- Internet Enhanced Service (IES)
- IES is a direct Internet access service where the SAP is assigned an IP interface for routed connectivity.
- Virtual Private LAN Service (VPLS)
- VPLS provides a Layer 2 multipoint VPN service to end customers. Sites in a VPLS instance appear to be on the same LAN regardless of their location. The 7705 SAR-Hm series nodes can participate in BGP VPLS-based services and traditional T-LDP signaled services.
- Virtual Private Routed Network Service (VPRN)
- VPRN provides a Layer 3 VPN service to end customers. VPRN services provide MP-BGP peering with other PEs, configurable QoS policy and filtering, and VRF import and export policies.
Table 3 lists the supported pseudowire (PW) service types. The values are as defined in RFC 4446.
Table 3: Pseudowire Service Types
PW Service Type (Ethertype) | Value |
Ethernet tagged mode | 0x0004 |
Ethernet raw | 0x0005 |
8.3. Nokia Service Model
The 7705 SAR-Hm series of routers is deployed at the customer provider edge (PE). Services are provisioned on the router in order to facilitate the transport of communications data across an IP/MPLS network using the Ethernet or wireless interfaces available on the node. The data is formatted so that it can be transported in encapsulation tunnels created using Layer 3 generic routing encapsulation (GRE) MPLS.
The Nokia service model has four main logical components, referred to as (logical) service entities. The entities are: applications, service types, service access points (SAPs), and service destination points (SDPs) (see Service Entities). In accordance with the service model, the operator uses the (logical) service entities to construct an end-to-end service. The service entities are designed to provide a uniform, service-centric model for service provisioning. This service-centric design implies the following characteristics.
- Multiple services can be bound to a single application.
- Multiple service types can be bound to a single tunnel.
- Tunnel configurations are independent of the services they carry.
- Changes are made to a single service entity rather than to multiple ports on multiple devices. It is easier to change one tunnel rather than several services.
- The operational integrity of a service entity (such as a service tunnel or service endpoint) can be verified by one operation rather than through the verification of dozens of parameters, thereby simplifying management operations, network scalability, and performance.
- A failure in the network core can be correlated to specific subscribers and services.
- The following policies are applied to various services:
- QoS policies
- filter policies (IP and MAC)
Additional properties can be configured for bandwidth assignments and class of service on the appropriate entity.
8.4. Service Entities
The basic (logical) service entities in the service model used to construct an end-to-end service are:
Figure 4 shows an example of how the service entities relate to the service model. An application attachment point (for example, an Ethernet port, VLAN, or serial port) connects to a SAP. The SDPs define the entrance and exit points of service tunnels, which carry one-way traffic between the two routers (NOK-A and NOK-B). Configured SDPs are bound to a service or the service is auto-bound which automatically creates tunnels to far-end nodes. The binding of the service to SDPs is the final step in enabling the end-to-end service. In Figure 4, the entrance and exit points are over the wireless interface.
Traffic encapsulation occurs at the SAP and SDP. The 7705 SAR-Hm series supports the following SAP encapsulation types:
- Ethernet untagged or tagged
- IP
- raw serial character data on the serial ports
The 7705 SAR-Hm series supports GRE-MPLS encapsulation for SDPs.
For information on SAP encapsulation types, see SAP Encapsulation Types and Identifiers. For information on SDP encapsulation types, see SDP Encapsulation Types.
Figure 4: Service Entities and the Service Model
8.4.1. Applications
Every application must have a customer ID, which is assigned when the application service is created. To provision a service, a customer ID must be associated with the service at the time of service creation.
 | Note: The terms application, customers, and subscribers are used synonymously in this manual. When referring to SR OS manuals for further information, these terms may appear and are interchangeable. |
8.4.2. Service Types
Service types provide the traffic adaptation needed by customer attachment circuits (ACs). This (logical) service entity adapts customer traffic to service tunnel requirements. A VLL service is a point-to-point MPLS-based emulation service, also called Virtual Private Wire Service (VPWS). The 7705 SAR-Hm series provides Ethernet VLL (Epipe) service and BGP VPLS-based Layer 2 service.
The series also provides Ethernet layer (MAC-based) VPLS service (including management VPLS), raw socket IP transport service, as well as IP layer VPRN and IES services, that offer any-to-any connectivity within a Virtual Routing Domain or Generic Routing Domain, respectively.
8.4.2.1. Service Names
A service ID number must be associated with a service at the time of service creation. Once the service is created, an optional service name can be assigned to the service for use by commands that reference the service.
8.4.3. 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. Figure 5 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 prior to provisioning a service. Refer to the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide for more information about configuring a port.
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 5: Service Access Point (SAP)
8.4.3.1. 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.
8.4.3.1.1. 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 Figure 6). An example of dot1q use might be the case where 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 6: Multiple SAPs on a Single Port
8.4.3.1.1.1. 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.
8.4.3.2. 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 given 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))
8.4.4. Service Destination Points (SDPs)
Topics in this section include:
An SDP identifies the endpoint of a logical unidirectional service tunnel. The service tunnel provides a path from one service router to another.
In more general terms, SDP refers to the service tunnel itself. The SDP terminates at the far-end router, which is responsible for directing the flow of packets to the correct service egress SAPs on that device.
| Note: In this document and in command line interface (CLI) usage, SDP is defined as Service Destination Point. However, it is not uncommon to find the term SDP defined in several different ways, as in the following list. All variations of SDP have the same meaning:
|
When an SDP is bound to a service, the service is referred to as a distributed service. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP binding that binds the service to the service tunnel. Multiple SDPs to different far-end nodes are bound to a service to provide transport for SAPs to other nodes participating in that service.
When configured, an SDP has the following characteristics.
- An SDP is locally unique to a participating service router. The same SDP ID can appear on other service routers.
- An SDP uses either the system IP address or the cellular PDN interface IP address of the far-end edge router to locate its destination.
- An SDP is not specific to any one service or to any type of service. Once an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.
- All services bound to an SDP use the same SDP (transport) encapsulation type defined for the SDP (for example, GRE-MPLS).
- An SDP is a service entity used for service management. Even though the SDP configuration and the services carried within it are independent, they are related objects. Operations on the SDP affect all the services associated with the SDP. For example, the operational and administrative state of an SDP controls the state of services bound to the SDP.
- An SDP tunnel from a local device to the far-end device (router) requires a return SDP tunnel from the far end back to the local device. Each device must have an SDP defined for every remote router to which it wants to provide service. The SDP must be created before a distributed service can be configured.
- An SDP can be used to provide PW redundancy, where up to four spoke SDPs can be assigned to a service endpoint that acts as the managing entity to ensure service connection. For information on pseudowire redundancy, refer to the “Pseudo-wire Redundancy” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.
8.4.4.1. SDP Binding
To configure a distributed service pointing from NOK-A to NOK-B, the SDP ID on the NOK-A side (see Figure 7) must be specified during service creation in order to bind the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end devices cannot participate in the service (there is no service). To configure a distributed service pointing from NOK-B to NOK-A, a return SDP on the NOK-B side must similarly be specified.
Figure 7: SDP Tunnel Pointing from NOK-A to NOK-B
SDP configuration and binding is required for:
- Layer 2 services that use T-LDP signaling
- Layer 3 services that do not use multi-protocol BGP(MP-BGP) to advertise routes with auto-bind
For Layer 3 VPRN services that use MP-BGP to advertise routes, auto-bind can be configured on the service to automatically bind that service to SDPs with reachability to remote nodes that are participating in MP-BGP.
The VPRN auto-bind function has the following characteristics.
- SDPs can be configured while auto-bind is enabled.
- Configuring SDPs when auto-bind is enabled is not required in order to transport VPRN services between nodes participating in the same VPRN.
- Configured SDPs have higher precedence and the node will select the configured SDP and its attributes to tunnel traffic to the far-end node.
- Auto-bind does not require a return path SDP from a far-end router as long as auto-bind is enabled on that far-end router for the service. If auto-bind is not enabled on the far-end router, then a return path SDP to the local 7705 SAR-Hm series node is required.
- For Layer 2 services that use BGP signaling (BGP-VPLS and BGP-VPWS) to exchange label information for the service, auto-gre can be configured on the pseudowire template of the service to automatically bind that service to SDPs with reachability to remote nodes that are participating in the BGP-signaled Layer 2 service. For information about the auto-GRE function available for BGP-VPLS and BGP-VPWS, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.
8.4.4.2. Spoke and Mesh SDPs
There are two types of SDPs: spoke and mesh. The type of SDP defines how flooded traffic (or broadcast traffic, such as an ARP request) is propagated. For point-to-point PW/VLL services, spoke SDPs are the only way to bind services to the far-end router. For VPLS, mesh and spoke SDP bindings are allowed.
A spoke SDP that is bound to a service operates like a traditional bridge port. Flooded traffic that is received on the spoke SDP is transmitted to all the spoke SDPs, mesh SDPs, and SAPs to which it is connected. Flooded traffic is not transmitted back toward the port from which it was received.
In contrast, a mesh SDP that is bound to a service operates like a single bridge port. Flooded traffic received on a mesh SDP is transmitted to all spoke SDPs and SAPs to which it is connected. Flooded traffic is not transmitted to any other mesh SDPs or back toward the port from which it was received. This property of mesh SDPs is important for multi-node networks; mesh SDPs are used to prevent the creation of routing loops.
8.4.4.3. SDP Encapsulation Types
The Nokia service model uses encapsulation tunnels (also referred to as service tunnels) through the core to interconnect service routers. An SDP is a logical way of referencing the entrance to an encapsulation tunnel.
The following encapsulation type is supported:
- Layer 2 or Layer 3 services within generic routing encapsulation (GRE-MPLS encapsulation)
An SDP has an implicit maximum transmission unit (MTU) value because services are carried in encapsulation tunnels and an SDP is an entrance to the tunnel. The MTU is configurable (in octets), where the transmitted frame can be no larger than the MTU.
8.4.4.3.1. GRE Encapsulation
Generic routing encapsulation (GRE) tunnels are used to transport network layer packets over a Layer 3 network such as an LTE or WLAN interface.
GRE-MPLS SDPs are supported on network interfaces.
8.4.4.3.1.1. GRE Format
In accordance with RFC 2784, a GRE encapsulated packet has the following format:
- delivery header
- GRE header
- payload packet
Delivery Header
The delivery header is always an IPv4 header.
GRE Header
The GRE header format is shown in Figure 8 and described in Table 4.
Figure 8: GRE Header
Table 4: GRE Header Descriptions
Field | Description |
C | Specifies whether there is a checksum in the header If set to 1, both the checksum and reserved1 fields must be present In the network egress (transmit) direction, the C bit is always set to 0; therefore, the checksum and reserved1 fields are omitted from the header. The GRE header is therefore always 4 bytes (32 bits) in the network egress direction. In the network ingress direction, the C bit validity is checked. If it is set to a non-zero value, the GRE packet is discarded and the IP discards counter is increased. |
Reserved0 | Indicates whether the header contains optional fields The first 5 bits of the field are always set to 0 and bits 6 to 12 are reserved for future use and also set to 0 |
Ver | Always set to 000 for GRE At network ingress, if a GRE packet is received with the version field set to any value other than 000, the packet is discarded and the IP discards counter is increased |
Protocol Type | Specifies the protocol type of the original payload packet—identical to Ethertype with the only supported option being MPLS unicast (0x8847) |
Checksum (optional) | Not applicable |
Reserved1 (optional) | Not applicable |
Payload Packet
The payload encapsulation format depends on the type of service that is being carried over GRE-MPLS. The payload encapsulation format for GRE services is shown in Figure 9 and described in Table 5.
Figure 9: GRE Service Payload Packet over Ethernet
Table 5: GRE Service Payload Packet Descriptions
Field | Description |
Eth | The Layer 2 transport header The only Layer 2 protocol supported is Ethernet MTU size depends on the encapsulation type (14 bytes for null encapsulation and 18 bytes for dot1q encapsulation) The Ethertype is always set to IP (0x800) |
IP | Indicates the transport protocol IPv4 is the transport protocol for GRE-MPLS |
GRE | Indicates the encapsulation protocol |
MPLS service header | The MPLS service label identifies the service and the specific service element being transported For VLL and VPWS services, the label references the pseudowire that was statically configured, or signaled via T-LDP or BGP signaling For VPLS services, the label references a particular VPLS pseudowire that was signaled via T-LDP or BGP signaling to allow the end-to-end VPLS service For VPRN services, the label references either a spoke SDP pseudowire associated with the VPRN, or an MP-BGP advertised route that has been signaled via BGP to allow the end-to-end VPRN service |
CW for VLL and VPWS | The pseudowire Control word (CW) is a 32-bit (4-byte) field that is inserted between the VC label and the Layer 2 frame For more information on the Control word, refer to the “Pseudo-wire Control Word” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN. |
Services payload | The services payload is the payload of the service being encapsulated For VLL, VPWS, and VPLS, this is a Layer 2 frame with either null or with dot.1q encapsulation For VPRN, this is a Layer 3 IPv4 or IPv6 packet without Layer 2 information |
At network egress over a cellular port, the destination IP address of the GRE-MPLS IP header is always the far-end IP address that was either configured for the SDP, or learned through BGP routing. If the far-end address is for a cellular port on another 7705 SAR-Hm series node, then that address could be either the system IP address or the cellular PDN interface IP address, depending on the mode of operation deployed at that far-end location. The source IP address of the GRE-MPLS IP header will always be set to the cellular PDN interface IP address. This address may be statically configured or dynamically assigned to a cellular port. For information about the PDN router interface modes of operation and how the PDN router interface IP address is assigned, see PDN Router Interfaces.
At the cellular port network ingress, the destination IP address in the IP header is the same as the cellular PDN interface IP address, since this IP address is the only address reachable over the LTE network. The source IP address of the IP header matches the far-end IP address associated with the GRE-MPLS tunnel. If the packet originated from another cellular port over the cellular network, the source IP address will match the cellular IP address used by the remote node. If the packet originated from another node that is Ethernet connected, then the source IP address is typically the system IP address of those nodes.
At network egress over an Ethernet interface, the source IP address is always set to the node system IP address; the destination IP address is set to one of the following:
- the system IP address of the service router on which the GRE SDP is configured
- the far-end interface address
- a loopback address
8.4.4.3.2. GRE SDP Tunnel Fragmentation and Reassembly
It is possible to transport services over GRE-MPLS tunnels when the service MTU is larger than the cellular interface MTU. This requires the GRE-MPLS packets to be fragmented and reassembled using GRE SDP fragmentation and reassembly operations. Refer to “GRE SDP Tunnel Fragmentation and Reassembly” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide.
8.4.4.3.3. GRE SDP Termination on Router Interface IP Address
In some applications, an Ethernet interface is required to operate as a network interface and originate and terminate GRE-MPLS packets. If the application requires that GRE-MPLS packets terminate on the interface IP address instead of on the system IP address, then GRE SDP termination on the router interface IP address functionality is available. Refer to “GRE SDP Termination on Router Interface IP Address” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide.
8.4.4.4. SDP Ping
For general information on SDP ping support, refer to the “SDP Ping” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR OAM and Diagnostics Guide.
8.5. Services over the Cellular PDN Interface
When configuring services to and from the node over the cellular PDN interface, the following points should be considered:
- The mode of operation that is required for the cellular PDN interface, either static cellular system IPv4, static cellular interface IPv4, dynamic cellular interface IPv4, static cellular interface IPv6, or dynamic cellular interface IPv6. See PDN Router Interfaces for information about each mode of operation.
- The service type that is required; for example, a VLL, VPLS, or VPRN. See Layer 2 and Layer 3 Services for information about supported service types.
- The signaling type that is required, either T-LDP, BGP, or both. See MPLS and Router Configuration for information about configuring signaling and routing.
- The routing and reachability of the node for each configured service type when the node is operating with two SIMs. For information on dual SIM deployment, refer to the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide, “Dual SIM Deployment”.
The combinations of considerations from the list above will result in different configuration requirements when enabling services over a cellular port.
The mode of operation of the cellular port for each enabled SIM is the main consideration when enabling services over cellular. Figure 10 shows an example of the IPv4 modes of operation. The points to consider for enabling services over cellular for each mode of operation are described below.
Figure 10: IPv4 Modes of Operation on the Cellular PDN Interface
8.5.1. Static Cellular System IPv4 Mode
When a PDN router interface is configured for static cellular system IPv4 mode, consider the points listed below when setting up a service over a PDN router interface and its associated cellular port.
- The system IP address used to manage the node is the same as the cellular PDN interface IP address that gets assigned during the cellular attachment procedure.
- SDPs that are destined to the local node from other nodes must be configured to use the system IP address (identical to the cellular IP address) of the local node as the far-end address.
- T-LDP signaling sessions from the local node to peers use the system IP address as the local address for these sessions. This is the default behavior of the SR OS. The T-LDP sessions from peer nodes to the local node must be established to the system IP address.
- BGP sessions from the local node to peers where BGP VPWS, BGP VPLS, MP-BGP, or BGP routing is required for services use the system IP address as the local address for sessions. This is the default behavior of the SR OS. BGP sessions from peer nodes to the local node must be established to the system IP address.
- Static cellular system IPv4 mode supports all service types.
- In a dual SIM deployment, static cellular system IPv4 mode requires that the same IP address be allocated for both SIMs. The single system IP address allocation depends on this requirement being met. This requirement can be challenging to meet in most deployment models. Static cellular interface IP mode or dynamic cellular interface IP mode should be considered when dual SIM is required, as these modes allow different IP addresses to be allocated for each SIM.
8.5.2. Static Cellular Interface IPv4 Mode
When a PDN router interface is configured for static cellular interface IPv4 mode, consider the points listed below when setting up a service over a PDN router interface and its associated cellular port.
- The system IP address used to manage the node is not the same as one of the cellular PDN interface IP addresses assigned during the cellular attachment procedure.
- SDPs that are destined to the local node from other nodes must be configured to use the PDN interface IP address of the local node as the far-end address. They must not use the system IP address of the local node as the far-end address.
- T-LDP signaling sessions from the local node to peers must use the PDN interface IP address as the source IP address for these sessions; otherwise, GRE-MPLS services will not function properly. Operators must use the local-lsr-id LDP command to specify that the PDN router interface address is the local LSR ID on this 7705 SAR-Hm for these T-LDP sessions. For information about configuring the local-lsr-id, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide. When the local-lsr-id is configured, T-LDP sets the source IP address of session packets to the PDN interface IP address.
- BGP sessions from the local node to peers where BGP VPWS, BGP VPLS, MP-BGP, and BGP routing is required for services must use the PDN interface IP address as the source IP address for these sessions. If these sessions do not use the PDN interface IP address as the source IP address, then GRE-MPLS services that require BGP-advertised information will not function properly.Operators must configure the BGP local-address command to specify that the PDN router interface is the local address on the local 7705 SAR-Hm series node for these BGP sessions. For information about configuring the BGP local address, see Using a Router Interface Address as the BGP Local Address. When the local-address is configured, BGP sets the source IP address of session packets to the PDN interface IP address.
- Static cellular interface IPv4 mode supports all service types.
When dual SIM operation is required, the points listed above must be considered for each PDN router interface configured for each SIM.
8.5.3. Dynamic Cellular Interface IPv4 Mode
When a PDN router interface is configured for dynamic cellular interface IPv4 mode, consider the points listed below when setting up a service a over PDN router interface and its associated cellular port.
- The system IP address used to manage the node is not the same as the cellular PDN interface IP address assigned during the cellular attachment procedure.
- The PDN interface IP address changes every time the PDN reattaches to the cellular network
- SDP configurations cannot be made from other nodes to the local node. The changing IP address of the PDN interface during each PDN attachment procedure inhibits the static configuration needed to manually configure SDPs.
- T-LDP signaling sessions cannot be established towards the local node because the changing PDN interface IP address inhibits the static configuration of T-LDP sessions towards the PDN interface.
- BGP sessions cannot be established towards the local node because the changing PDN interface IP address inhibits the static configuration of BGP sessions towards the PDN interface.
- BGP sessions from the local node to peers where MP-BGP and BGP routing is required for services must use the PDN interface IP address as the source IP address for these sessions. Operators must specify the loopback interface of the PDN router interface when configuring the BGP local-address command. For information about configuring the BGP local address, see Using a Router Interface Address as the BGP Local Address. When the local-address command is configured with the loopback interface of the PDN router interface, BGP sets the source IP address of session packets to the PDN interface IP address.
- BGP far-end peering nodes to the local node must be configured with the dynamic-neighbor command using an IP address range that matches the possible PDN router interface attachment IP addresses on the local node. This allows the PDN interface IP address to dynamically change and re-establish BGP sessions to the same far-end peering node. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide for information about the dynamic-neighbor command.
- Only services that use auto-bind or auto-gre-sdp can operate with dynamic cellular interface IP mode. The 7705 SAR-Hm series supports MP-BGP-based VPRN services with auto-bind, and BGP-VPLS and BGP-VPWS with auto-gre-sdp.
- Dynamic cellular interface IP mode does not support the following services:
- Layer 2 services that use T-LDP signaling
- Layer 3 services that do not use auto-bind
When dual SIM operation is required, the points listed above must be considered for each PDN router interface configured for each SIM.
8.5.4. Static Cellular Interface IPv6 Mode
When a PDN router interface is configured for static cellular interface IPv6 mode, consider the points listed below when setting up a service over a PDN router interface and its associated cellular port.
- GRE-MPLS based services are not supported with static cellular interface IPv6 mode.
- Services that are supported using IPSec secure interfaces are supported with static cellular interface IPv6 mode.
In a dual SIM deployment, the points listed above must be considered for each PDN router interface configured for each SIM.
8.5.5. Dynamic Cellular Interface IPv6 Mode
When a PDN router interface is configured for dynamic cellular interface IPv6 mode, consider the points listed below when setting up a service over a PDN router interface and its associated cellular port.
- GRE-MPLS based services are not supported with dynamic cellular interface IPv6 mode.
- Services that are supported using IPSec secure interfaces are supported with dynamic cellular interface IPv6 mode.
In a dual SIM deployment, the points listed above must be considered for each PDN router interface configured for each SIM.
8.6. Transporting WLAN Interface Traffic over Services
When available, the WLAN interface can be used to provide connectivity to other devices. As an access point (AP), the WLAN interface brings device traffic into a service SAP, which is then carried over an SDP and ultimately over a network WAN interface such as an Ethernet port or a cellular port. The port ID of the WLAN interface is used as the SAP ID that binds the WLAN interface to the service. For information about configuring WLAN MDA and port parameters to enable the WLAN interface, refer to the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide.
To provide services from the WLAN interface AP to other nodes and devices in the network, a Layer 2 Epipe service is required. The Epipe either connects the WLAN AP to the Nokia WLAN gateway (WLAN-GW) enabled on the VSR or 7750 SR, or back hauls the WLAN AP traffic to other nodes in the network. For information about configuring the WLAN-GW, refer to the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.
WLAN clients can be optionally authenticated by an AAA server before being allowed access to the WLAN AP and before their traffic can be carried over the transport service.
8.6.1. Layer 2 Epipe Service to the WLAN-GW
The WLAN interface AP can connect directly to the WLAN Gateway (WLAN-GW) over a Layer 2 Epipe service. For information about the WLAN-GW, refer to "WiFi Aggregation and Offload" in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.
Figure 11 illustrates the use of an Epipe service to connect the WLAN AP on a 7705 SAR-Hm to the WLAN-GW.
Figure 11: Using an Epipe to Connect a WLAN AP to a WLAN-GW
In Figure 11, to connect to the WLAN-GW, the WLAN interface AP port ID must be configured as the L2 SAP of an Epipe service. The Epipe service is configured with a spoke SDP where the far-end address of the SDP (GRE) is configured to reach the gateway address of the WLAN-GW.
There is no signaling required to establish the Epipe service because a static ingress and egress VC label must be configured with the same value. The VC label received by the WLAN-GW from the WLAN AP node (the egress VC label) is reflected back from the WLAN-GW for traffic destined to the WLAN AP node. The 7705 SAR-Hm uses the received VC label (the ingress VC label) to determine that the received traffic is for the Epipe service associated with the WLAN AP SAP.
If the same SSID is used for multiple WLAN APs in the network (for example, an enterprise SSID for a campus-wide WLAN network), the same VC label should be used for each WLAN AP Epipe participating in the same SSID network WLAN service. Using a unique VC label per SSID allows WLAN clients connecting to the SSID to roam between WLAN APs that are broadcasting the same SSID.
The output below shows a configuration example of the SDP and Epipe SAP.
The WLAN AP authenticates users before forwarding their traffic over the Epipe. For information about security parameters and supported authentication protocols, refer to the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide.
DHCP snooping and DHCP relay must be enabled on the WLAN AP so that attached clients can successfully acquire an IP address from the WLAN GW when they issue DHCP requests. The WLAN AP snoops for DHCP requests and modifies them to include DHCP option 82, specifically the circuit ID sub-option that includes the MAC address of the AP, the SSID of the AP, and the SSID type of either open or secured. The DHCP request is then relayed to the WLAN GW over the Epipe service. To enable DHCP snooping and DHCP relay on the WLAN port, the command config>port>wlan>access-point>dhcp>no shutdown must be executed in the CLI. For more information, refer to the 7705 SAR-Hm and SAR-Hmc Interface Configuration Guide.