2.14. Configuring Global Service Entities with CLI
This section provides information to create subscriber (customer) accounts using the command line interface.
2.14.1. Service Model Entities
The Nokia service model uses logical entities to construct a service. The service model contains four main entities to configure a service.
2.15. Basic Configuration
The most basic service configuration must have the following:
- customer ID
- service type
- service ID
- SAP identifying a port and encapsulation value
2.16. Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure a customer account
2.16.1. Configuring Customer Accounts
Subscribers
The most basic customer account must have a customer ID. Optional parameters include:
- description
- contact name
- telephone number
2.16.1.1. Customer Information
Use the following syntax to create and input customer information.
The following is a sample basic customer account configuration output.
2.17. Service Creation Process Overview on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Figure 13 shows the overall process to provision core and subscriber services.
 | Note: Service creation with MPLS uplinks using SDPs for interconnecting routers is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C. |
Figure 13: Service Creation and Implementation Flow
2.17.1. Deploying and Provisioning Services on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
The service model provides a logical and uniform way of constructing connectivity services. The basic steps for deploying and provisioning services can be broken down into three phases.
2.17.1.1. Phase 1: Core Network Construction
Before the services are provisioned, the following tasks should be completed:
- Build the IP or IP/MPLS core network.
- Configure routing protocols.
- Configure MPLS LSPs (if MPLS is used).
- Configure access-uplink SAPs (if only Layer 2 uplinks are desired).
2.17.1.2. Phase 2: Service Administration
Perform preliminary policy configurations to control traffic flow, operator access, and to manage fault conditions and alarm messages, the following tasks should be completed:
- Configure group and user access privileges.
- Build templates for QoS, filter and/or accounting policies needed to support the core services.
2.17.1.3. Phase 3: Service Provisioning
- Provision customer account information.
- If necessary, build any customer-specific QoS, filter or accounting policies.
- Provision the customer services on the service edge routers by defining SAPs, binding policies to the SAPs.
2.17.2. Configuration Notes
This section describes service configuration caveats.
2.17.2.1. General
Service provisioning tasks can be logically separated into two main functional areas, core tasks and subscriber tasks and are typically performed before provisioning a subscriber service.
Core tasks include the following:
- Create customer accounts
- Create template QoS, filter, scheduler, and accounting policies
- Create SDPs (if using MPLS uplinks)
Subscriber services tasks include the following:
- Create Epipe and VPLS services.
- Create a VPRN service
- Bind SDPs (if using MPLS uplinks)
- Configure interfaces (where required) and SAPs
- Create exclusive QoS and filter policies
2.17.3. Configuring Global Service Entities with CLI
This section provides information to create subscriber (customer) accounts using the command line interface.
2.17.3.1. Service Model Entities
The Nokia service model uses logical entities to construct a service. The service model contains four main entities to configure a service.
2.17.4. Basic Configuration
The most basic service configuration must have the following:
- customer ID
- service type
- service ID
- SAP identifying a port and encapsulation value
- associated SDP for distributed services using MPLS uplinks.
The following is a sample Epipe service configuration output showing the SDP and Epipe service entities. SDP ID 1 was created with the far-end node 10.20.1.2. Epipe ID 101 was created for customer ID 1, which uses the SDP ID 1.
2.17.5. Common Configuration Tasks
This section provides a brief overview of the tasks performed to configure a customer account and an SDP. SDP configuration is not needed when 7210 SAS devices are configured to use only access-uplink ports.
2.17.5.1. Configuring Customer Accounts
The most basic customer account must have a customer ID. Optional parameters include:
- description
- contact name
- telephone number
2.17.5.2. Customer Information
Use the following syntax to create and input customer information.
The following is a sample basic customer account configuration output.
2.17.5.3. Configuring an SDP
The most basic SDP must have the following:
- locally unique SDP identification (ID) number
- system IP address of the far-end routers
- SDP encapsulation type, MPLS
2.17.5.4. SDP Configuration Tasks
This section provides a brief overview of the tasks performed to configure SDPs, and provides the CLI commands.
Consider the following SDP characteristics:
- SDPs can be created as MPLS.
- Each distributed service must have an SDP defined for every remote router to provide VLL, VPLS, IES and VPRN services.
- A distributed service must be bound to an SDP. By default, no SDP is associated with a service. When an SDP is created, services can be associated to that SDP.
- An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than one service bound to it.
- The SDP IP address must be a 7210 SAS-series system IP address.
- To configure an MPLS SDP, LSPs must be configured first, then the LSP-to-SDP association must be explicitly created.
- In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a TLDP connection between two 7210 SAS-series routers.
| Note: If signaling is disabled for an SDP, services using that SDP must configure ingress and egress VC labels manually. |
To configure a basic SDP, perform the following steps:
- Specify an originating node.
- Create an SDP ID.
- Specify an encapsulation type.
- Specify a far-end node.
2.17.6. Configuring an SDP
Use the following CLI syntax to create an SDP and select an encapsulation type. Only MPLS encapsulation is supported.
| Note: When you specify the far-end IP address, you are creating the tunnel; you are creating the path from point A to point B. When you configure a distributed service, you must identify an SDP ID. Use the show service sdp command to display the qualifying SDPs. |
When specifying MPLS SDP parameters, you must specify an LSP. If an LSP name is specified, RSVP is used for dynamic signaling within the LSP.
LSPs are configured in the config>router>mpls context. Refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guide for configuration and command information.
Use the following syntax to create an MPLS SDP.
The following is a sample LSP-signaled MPLS SDP configuration output.
2.17.7. Configuring a Mixed-LSP SDP
The following shows the command usage to configure an SDP with mixed-LSP mode of operation:
config>service>sdp mpls>mixed-lsp-mode
The primary is backed up by the secondary. Two combinations are possible: the primary of RSVP is backed up by LDP and the primary of LDP is backed up by 3107 BGP.
The no form of this command disables the mixed-LSP mode of operation. The user first has to remove one of the LSP types from the SDP configuration or the command will fail.
The user can also configure how long the service manager must wait before it reverts the SDP to a higher priority LSP type, when it becomes available, by using the following command:
config>service>sdp mpls>mixed-lsp-mode>revert-time revert-time
An infinite value for the timer dictates that the SDP must never revert to another higher priority LSP type unless the currently active LSP type is down:
config>service>sdp mpls>mixed-lsp-mode>revert-time infinite
The BGP LSP type is allowed. The bgp-tunnel command can be configured under the SDP with the lsp or ldp commands.
2.18. ETH-CFM
ETH-CFM is defined in two similar standards: IEEE 802.1ag and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects to support transport fault management, including discovery and verification of the path, detection and isolation of a connectivity fault for each Ethernet service instance.
ETH-CFM configuration is split into multiple CLI contexts. The base ETH-CFM configuration, that defines the different management constructs and administrative elements, is performed in the eth-cfm context. The individual management points are configured within the specific service contexts in which they are applied (port, SAP, and so on).
Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for detailed information about the basic service-applicable material to build the service-specific management points, MEPs, and MIPs. The different service types support a subset of the features from the complete ETH-CFM suite.
The supported features vary across services and depending on different 7210 SAS platforms.
The troubleshooting tools ETH-LBM, ETH-LBR, LTM ETH-TST, and LTR ETH-TST, defined by the IEEE 802.1ag specification and the ITU-T Y.1731 recommendation, are applicable to all MEPs (and MIPs where appropriate). The advanced notification function, Alarm Indication Signal (AIS), defined by the ITU-T Y.1731, is supported on Epipe services.
The advanced performance functions, 1DM, DMM/DMR, and SLM/SLR, are supported on all service MEPs.
Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C OAM and Diagnostics Guide for a description of the individual features and functions that are supported.
Table 10 lists ETH-CFM acronym expansions.
Table 10: Service Endpoint and MEP/MIP Acronyms
Acronym | Expansion |
1DM | One-way Delay Measurement (Y.1731) |
AIS | Alarm Indication Signal |
BNM | Bandwidth Notification Message (Y.1731 sub OpCode of GMN) |
CCM | Continuity Check Message |
CFM | Connectivity Fault Management |
DMM | Delay Measurement Message (Y.1731) |
DMR | Delay Measurement Reply (Y.1731) |
GNM | Generic Notification Message |
LBM | Loopback Message |
LBR | Loopback Reply |
LTM | Linktrace Message |
LTR | Linktrace Reply |
ME | Maintenance Entity |
MA | Maintenance Association |
MA-ID | Maintenance Association Identifier |
MD | Maintenance Domain |
MEP | Maintenance Association Endpoint |
MEP-ID | Maintenance Association Endpoint Identifier |
MHF | MIP Half Function |
MIP | Maintenance Domain Intermediate Point |
OpCode | Operational Code |
RDI | Remote Defect Indication |
TST | Ethernet Test (Y.1731) |
SLM | Synthetic Loss Message (Y.1731) |
SLR | Synthetic Loss Reply (Y.1731) |
ETH-CFM capabilities may be deployed in many different Ethernet service architectures. The Ethernet-based SAPs and SDP bindings provide the endpoint on which the management points may be created. The basic functions can be used in different services, VPLS and Epipe. Figure 14 and Figure 15 show two possible scenarios for ETH-CFM deployment in Ethernet access and aggregation networks.
Figure 14: Ethernet OAM Model for Ethernet Access - Business
Figure 15: Ethernet OAM Model for Ethernet Access - Wholesale
The following functions are supported.
- On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T, CFM can be enabled or disabled on a per-SAP basis.
- On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, CFM can be enabled or disabled on a per-SAP and per-SDP binding basis.
- The eight ETH-CFM levels are suggested to be broken up numerically between customer 7 to 5, service provider 4 to 3 and operator 2 to 1.
- Level 0 typically is meant to monitor direct connections without any MIPs and should be reserved for port-based G8032 MEPs.
- Down MEP and Up MEP with an MEP-ID on a SAP/SDP binding for each MD level can be configured, modified, or deleted. Each MEP is uniquely identified by the MA-ID and MEP-ID tuple.
- MEP creation on a SAP is only allowed for Ethernet ports (with null, Q-tags, QinQ encapsulations).
- MEP support in different services and the endpoints configured in the services (SAPs, SDPs, IP interfaces, and so on) varies across services and 7210 platforms. The following table lists the support available for MEP on different 7210 platforms.
- On 7210 SAS-D and 7210 SAS-Dxp, Up MEPs cannot be created by default on system boot-up. The user needs to explicitly allocate hardware resources for use with Up MEP feature, using the commands in the configure>system>resource- profile context. Only after resources have been allocated by the user, Up MEPs can be created. Until resources are not allocated to Up MEP, the software fails all attempts to create an Up MEP.
- On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, no explicit resource allocation is required before configuring Up MEPs.
- MIP creation on a SAP for each MD level can be enabled and disabled. MIP creation is automatic or manual when it is enabled. When MIP creation is disabled for an MD level, the existing MIP is removed.
- The 7210 SAS-D and 7210 SAS-Dxp have the notion of ingress and egress MIPs. That is, on these platforms, MIPs are not bidirectional by default. Ingress MIP responds to OAM messages that are received. Egress MIP responds to OAM messages that are sent. Ingress and egress MIP support for SAP, SDP Bindings and services varies and is listed in Table 11. For more information about MEP and MIP support, see MEP and MIP Support.
- On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, all MIPs are bidirectional. MIP responds to OAM messages that is received from the wire and also responds to OAM messages that is being sent out to the wire. MIP support for SAP, SDP bindings, and services varies and is listed in Table 11. For more information about MEP and MIP support, see MEP and MIP Support.
2.18.1. Common Actionable Failures
AIS operates independently from the low-priority-defect setting. The low-priority-defect setting configuration parameter affects only the ETH-CFM fault propagation and alarming outside the scope of AIS. Any fault in the MEP state machine generates AIS when it is configured. Table 11 describes the ETH-CC defect condition groups, configured low-priority-defect setting, priority, and defect as it applies to fault propagation.
Table 11: ETH-CC Defect Condition Groups
Defect | Low Priority Defect | Description | Causes | Priority |
DefNone | N/A | No faults in the association | Normal operations | N/A |
DefRDICCM | allDef | Remote Defect Indication | Feedback mechanism to inform that unidirectional faults exist. It provides the feedback loop to the node with the unidirectional failure conditions. | 1 |
DefMACStatus (default) | macRemErrXcon | MAC Layer | Remote MEP is indicating that a remote port or interface is not operational. | 2 |
DefRemoteCCM | remErrXon | No communication from remote peer | MEP is not receiving CCM from a configured peer. The timeout of CCM occurs at 3.5 times the local CC interval. As per the specification, this value is not configurable. | 3 |
DefErrorCCM | errXcon | Remote and local configurations do not match required parameters | Caused by different interval timer, domain-level issues (lower value arriving at a MEP configured with a higher value), MEP receiving CCM with its MEPID | 4 |
DefXconn | Xcon | Cross Connected Service | The service is receiving CCM packets from a different association. This could indicate that two services have merged or there is a configuration error on one of the SAPs or bindings of the service, incorrect association identification. | 5 |
2.18.2. MEP and MIP Support
Table 12, Table 13, Table 14, Table 15, and Table 16 are general tables that indicate the ETH-CFM support for the different services and endpoints. It is not meant to indicate the services supported or the requirements for those services on the individual platforms.
2.18.2.1. ETH-CFM Support for 7210 SAS-D
Table 12 lists the ETH-CFM support for the 7210 SAS-D.
Table 12: ETH-CFM Support Matrix for 7210 SAS-D
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
VPLS | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ 1 | |
R-VPLS | SAP | |||||
IES | IES IPv4 interface | |||||
SAP | ||||||
- Supported only with Up MEP and dot1q range SAPs. See Epipe Emulation Using Dot1q VLAN Range SAP in VPLS with G.8032 for more information.
Note:
2.18.2.2. ETH-CFM Support for 7210 SAS-Dxp
Table 13 lists the ETH-CFM support for the 7210 SAS-Dxp.
Table 13: ETH-CFM Support Matrix for 7210 SAS-Dxp
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
VPLS | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ 1 | |
R-VPLS | SAP | |||||
IES | IES IPv4 interface | |||||
SAP | ||||||
- Supported only with Up MEP and dot1q range SAPs. See Epipe Emulation Using Dot1q VLAN Range SAP in VPLS with G.8032 for more information.
Note:
2.18.2.3. ETH-CFM Support for 7210 SAS-K 2F1C2T
Table 14 lists the ETH-CFM support for the 7210 SAS-K 2F1C2T.
Table 14: ETH-CFM Support Matrix for 7210 SAS-K 2F1C2T
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | ✓ 1 |
VPLS | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
R-VPLS | SAP | |||||
IES | IES IPv4 interface | |||||
SAP | ||||||
- Supported for Up MEPs only
Note:
2.18.2.4. ETH-CFM Support for 7210 SAS-K 2F6C4T
Table 15 lists ETH-CFM support for 7210 SAS-K 2F6C4T.
Table 15: ETH-CFM Support Matrix for 7210 SAS-K 2F6C4T
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
Spoke-SDP | ✓ | ✓ | ✓ | ✓ | ||
VPLS | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
Spoke-SDP | ✓ | ✓ | ✓ | ✓ | ||
Mesh-SDP | ✓ | ✓ | ||||
R-VPLS | SAP | |||||
IP interface (IES or VPRN) | ||||||
IES | IES IPv4 interface | |||||
SAP | ||||||
2.18.2.5. ETH-CFM Support for 7210 SAS-K 3SFP+ 8C
Table 16 lists the ETH-CFM support for the 7210 SAS-K 3SFP+ 8C.
Table 16: ETH-CFM Support Matrix for 7210 SAS-K 3SFP+ 8C
Service | Ethernet Connection Type | MEP | MIP | Primary VLAN | ||
Down MEP | Up MEP | Ingress MIP | Egress MIP | |||
Epipe | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | ✓ 1 |
Spoke-SDP | ✓ | ✓ | ✓ | ✓ | ||
VPLS | SAP (access and access-uplink SAP) | ✓ | ✓ | ✓ | ✓ | |
Spoke-SDP | ✓ | ✓ | ✓ | ✓ | ||
Mesh-SDP | ✓ | ✓ | ||||
R-VPLS | SAP | |||||
IP interface (IES or VPRN) | ||||||
IES | IES IPv4 interface | |||||
SAP | ||||||
- Supported for Up MEPs only
Note:
| Note: Ethernet-Rings are not configurable under all service types. Any service restrictions for MEP direction or MIP support will override the generic capability of the Ethernet-Ring MPs. For more information about Ethernet-Rings, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide. |
2.18.3. Configuring ETH-CFM Parameters
Configuring ETH-CFM requires commands at two different hierarchy levels of the CLI.
This section provides a sample of the global ETH-CFM configuration, which defines the domains, associations, linkage of the service ID or function, and the globally applicable CCM parameters, including the interval and building of the remote MEPs database.
The following is a sample configuration output.
Defining the MEP and configuring service-specific ETH-CFM parameters is performed within the service on the specific SAP or SDP binding. The example using the service VPLS 100 shows this configuration on the SAP.
The preceding samples were based on IEEE 802.1ag. They are not capable of running Y.1731 functions. To build a Y.1731 context, the domain format must be none.
The following are samples of the global ETH-CFM configuration output and the advanced Y.1731 functions that can be configured. The configuration will reject the configuration of Y.1731 functions within an IEEE 802.1ag context.
| Note:
|
2.19. Service Management Tasks
This section describes the service management tasks.
2.19.1. Modifying Customer Accounts
To access a specific customer account, you must specify the customer ID.
To display a list of customer IDs, use the show service customer command.
Enter the parameters (description, contact, phone), then enter the new information.
2.19.2. Deleting Customers
The no customer command removes a customer ID and all associated information. All service references to the customer must be shut down and deleted before a customer account can be deleted.