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 Customers
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 L2 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:
- A customer ID
- A service type
- A service ID
- A SAP identifying a port and encapsulation value
- An associated SDP for distributed services using MPLS uplinks.
The following is a sample Epipe service configuration output displaying 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 Customers
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:
- A locally unique SDP identification (ID) number.
- The system IP address of the far-end routers.
- An 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 and 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. In essence, 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, then 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: primary of RSVP is backed up by LDP and 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
A special value of 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. Ethernet Connectivity Fault Management
Table 10: Service Endpoint and MEP/MIP Acronyms
Acronym | Expansion |
1DM | One way Delay Measurement (Y.1731) |
AIS | Alarm Indication Signal |
CCM | |
CFM | |
DMM | Delay Measurement Message (Y.1731) |
DMR | Delay Measurement Reply (Y.1731) |
Generic Notification Message | |
LBM | |
LBR | |
LTM | |
LTR | |
ME | |
MA | |
MA-ID | |
MD | |
MEP | |
MEP-ID | |
MHF | |
MIP | |
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
- 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-5, service provider 4-3 and Operator 2-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 allowed only for Ethernet ports (with null, Q-tags, qinq encapsulations).
- MEP support in different service and the endpoints configured in the service (SAPs, SDPs, IP interfaces, etc.) varies across service 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 is received from the wire. Egress MIP responds to OAM messages that is being sent out to the wire. 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
It is important to note that 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: sETH-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 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 a remote port or interface 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.5x the local CC interval. As per the specification, this value is not configurable. | 3 |
DefErrorCCM | errXcon | Remote and local configures 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 SAP or bindings of the service, incorrect association identification. | 5 |
2.18.2. MEP and MIP Support
Table 12, Table 13, Table 14, 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: ETH-CFM Support Matrix for 7210 SAS-D
Service | Ethernet Connection Type | Down MEP | MIP | Primary VLAN | |
Epipe | Yes | Yes | |||
VPLS | Yes | Yes | Ingress MIP only | ||
RVPLS | SAP | ||||
IES | IES IPv4 interface | ||||
SAP |
Note:
2.18.2.2. ETH-CFM Support for 7210 SAS-Dxp
Table 13: ETH-CFM Support Matrix for 7210 SAS-Dxp
Service | Ethernet Connection Type | Down MEP | MIP | Primary VLAN | |
Epipe | Yes | Yes | |||
VPLS | Yes | Yes | Ingress MIP only | ||
RVPLS | SAP | ||||
IES | IES IPv4 interface | ||||
SAP |
2.18.2.3. ETH-CFM Support for 7210 SAS-K 2F1C2T
Table 14 lists the ETH-CFM support for 7210 SAS-K 2F1C2T.
Table 14: ETH-CFM Support Matrix for 7210 SAS-K 2F1C2T
Service | Ethernet Connection Type | Down MEP | MIP | Primary VLAN | |
Epipe | Yes | Yes | |||
VPLS | Yes | Yes | |||
RVPLS | SAP | ||||
IES | IES IPv4 interface | ||||
SAP |
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 | Down MEP | Up MEP | MIP | Primary VLAN |
Epipe | Yes | Yes | |||
Spoke-SDP | Yes | Yes | |||
VPLS | Yes | Yes | |||
Spoke-SDP | Yes | Yes | |||
Mesh-SDP | Yes | Yes | |||
RVPLS | |||||
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: ETH-CFM Support Matrix for 7210 SAS-K 3SFP+ 8C
Service | Ethernet Connection Type | Down MEP | Up MEP | MIP | Primary VLAN |
Epipe | Yes | Yes | |||
Spoke-SDP | Yes | Yes | |||
VPLS | Yes | Yes | |||
Spoke-SDP | Yes | Yes | |||
Mesh-SDP | Yes | Yes | |||
R-VPLS | |||||
IP interface (IES or VPRN) | |||||
IES | IES IPv4 interface | ||||
SAP |
| 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, see 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.
A sample of the global ETH-CFM configuration which defines the domains, associations, linkage o the service id or function, and the globally applicable CCM parameters including the interval and building of the remote MEPs database is shown as follows.
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) and 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.