VLL Services Command Reference

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes the string from the context.

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they can be deleted. Many entities must be explicitly enabled using the no shutdown command.

The no form of this command places the entity into an administratively enabled state.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities are described in the following Special Cases.

This command configures a point-to-point ATM service. The Apipe service provides a point-to-point Layer 2 VPN connection to a local or remote SAP. An Apipe can connect an ATM endpoint locally (in the same 7705 SAR) or over a PSN to a remote endpoint of the same type.

Apipes support SAP aggregation groups in which multiple VCC SAPs can be bound in a single service.

This command configures a circuit emulation service using MPLS or GRE encapsulation. The vc-type defines the type of unstructured or structured circuit emulation service to be configured. All other parameters (service-id, customer) have common usage with other service types.

This command configures a point-to-point Ethernet service. An Epipe connects two endpoints defined as SAPs. Both SAPs are defined on separate routers (7705 SAR routers or other Nokia service routers) connected over the service provider network. When the endpoint SAPs are separated by the service provider network, the far-end SAP is generalized into an SDP. This SDP describes a destination 7705 SAR and the encapsulation method used to reach it.

No MAC learning or filtering is provided (or needed) on an Epipe.

When a service is created, the customer keyword and customer-id must be specified, which associates the service with a customer. The customer-id must already exist, having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified will result in an error.

By default, Epipe services do not exist until they are explicitly created with this command.

The no form of this command deletes the Epipe service instance with the specified service-id. The service cannot be deleted until the service has been shut down.

This command configures a point-to-point FR service. The Fpipe service provides a point-to-point Layer 2 VPN connection to a local or remote SAP. An Fpipe connects only FR endpoints. Endpoints can be connected locally (in the same 7705 SAR) or remotely over a PSN.

This command configures a point-to-point HDLC service.

This command configures an IP interworking service. An Ipipe can be configured as a SAP-to-SAP or SAP-to-SDP service. An Ipipe can connect the following types of SAPs over an MPLS or IP network:

This command provides access to the service endpoint context.

This command enables CE address discovery for an Ipipe service.

This command configures the time to wait before reverting back to the primary spoke SDP defined on this service endpoint, after having switched over to a backup spoke SDP after a failure of the primary spoke SDP.

Note: The infinite option (for non-revertive behavior) does not apply to Cpipes.

This command sends the pseudowire standby bit (value 0x00000020) to the targeted LDP (T-LDP) peer whenever a spoke SDP of the endpoint is selected as a standby (see precedence). This bit informs the far end that the pseudowire is not currently active.

This command blocks the spoke SDP from transmitting data when the pseudowire standby bit (value 0x00000020) is received from a targeted LDP (T-LDP) peer. In order to have standby-signaling-slave working properly end-to-end, standby-signaling-master must be enabled on the ingress LER (see standby-signaling-master).

If this command is enabled, the show service id id all command output shows the Flags field with a value of “StandbySigSlaveTxDown” and the Peer Pw Bits field with a value of “PwFwdingStandby”, indicating that transmission is blocked but the spoke SDP is still up.

The no form of the command disables the blocking of traffic in the transmit direction, and data received via the associated SAP or service continues to be transmitted.

This command configures the service payload (MTU), in octets, for the service. This MTU value overrides the service-type default MTU.

The service-mtu defines the payload capabilities of the service. It is used by the system to validate the SAP and SDP binding’s operational state within the service.

The service MTU and a SAP’s service delineation encapsulation overhead (4 bytes for a dot1q tag or 8 bytes for qinq tags) is used to derive the required MTU of the physical port or channel on which the SAP was created. If the required payload is larger than the port or channel MTU, the SAP will be placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP will be able to transition to the operative state.

When binding an SDP to a service, the service MTU is compared to the path MTU associated with the SDP. The path MTU can be administratively defined in the context of the SDP. The default or administrative path MTU can be dynamically reduced due to the MTU capabilities discovered by the tunneling mechanism of the SDP or the egress interface MTU capabilities based on the next hop in the tunnel path. If the service MTU is larger than the path MTU, the SDP binding for the service will be placed in an inoperative state. If the service MTU is equal to or less than the path MTU, then the SDP binding will be placed in an operational state.

In the event that a service MTU, port or channel MTU, or path MTU is dynamically or administratively modified, then all associated SAP and SDP binding operational states are automatically re-evaluated.

The no form of this command returns the default service-mtu for the indicated service type to the default value.

This command configures a service name that can be used for reference in configuration and show commands.

This command creates a SAP within a service. Each SAP must be unique.

All SAPs must be explicitly created with the create keyword. If no SAPs are created within a service or an IP interface, a SAP will not exist on that object.

To edit SAP parameters, enter an existing SAP without the create keyword.

A SAP can only be associated with a single service. The SAP is owned by the service in which it was created. A SAP can only be defined on a port that has been configured as an access port in the config>port port-id context using the mode access command, or on a Surveillance, Control, and Data Acquisition Support (SCADA) bridge that has been configured on an Integrated Services card using the config>scada command. The Integrated Services card is a resource card that does not have any ports; as well, it supports an access functionality only.

Fractional TDM ports are always access ports. Refer to the 7705 SAR OS Interface Configuration Guide.

If a port or SCADA bridge is shut down, all SAPs on that port or SCADA bridge become operationally down. When a service is shut down, SAPs for the service are displayed as operationally down and all traffic traversing the service is discarded. The operational state of a SAP is relative to the operational state of the port or SCADA bridge on which the SAP is defined.

The following SAP types are supported:

The no form of this command deletes the SAP with the specified port or SCADA bridge. When a SAP is deleted, all configuration parameters for the SAP will also be deleted.

SAPs that are configured with this command cannot be bound to a SAP aggregation group. See SAP Aggregation Group Commands for more information about the sap sap-id sap-aggregation-group group-id command, which is used to support N-to-one cell mode where N > 1.

This command assigns a specific MAC address to an Ipipe Ethernet SAP.

The no form of this command returns the MAC address of the SAP to the default value.

This command specifies the interval between ARP requests sent on an Ipipe Ethernet SAP. When the SAP is first enabled, an ARP request will be sent to the attached CE device and the received MAC address will be used in addressing unicast traffic to the CE. Although this MAC address will not expire while the Ipipe SAP is enabled and operational, it is verified by sending periodic ARP requests at the specified interval.

The no form of this command restores mac-refresh to the default value.

This command enables the context to configure IPCP. Within this context, IPCP extensions can be configured to define the remote IP address and DNS IP address to be signaled via IPCP on the associated PPP interface.

This command is only applicable if the associated SAP is a PPP/MLPPP interface.

This command assigns the IP address, defined by the config>service>ipipe>sap>ce-address command, to the far end of the associated PPP/MLPPP link via IPCP extensions. This command is only applicable if the associated SAP or port is a PPP/MLPPP interface with an IPCP encapsulation.

This command defines the DNS addresses to be assigned to the far end of the associated PPP/MLPPP link via IPCP extensions. This command is only applicable if the associated SAP or port is a PPP/ MLPPP interface with an IPCP encapsulation.

Use this command to configure frame relay properties for the SAP.

Use this command to configure Ethernet properties for the SAP.

This command enables Link Loss Forwarding (LLF) on an Ethernet port. LLF can only be enabled on Ethernet ports configured for null encapsulation.

LLF provides an end-to-end OAM fault notification for Ethernet VLL service. When LLF is enabled and there is a local fault on the pseudowire or service, or a remote fault on the SAP or pseudowire, the Ethernet port is brought down. Using label withdrawal or T-LDP status bits, LLF signals to connected equipment that the VLL is down. LLF stops signaling when the fault disappears.

The no form of the command disables LLF.

This command configures a SAP aggregation group on an Apipe. A SAP aggregation group group-id is a unique identifier on each node.

To configure an Apipe with a SAP aggregation group, the SAP aggregation group must be configured before any SAPs are bound to the Apipe. SAPs that are to be bound to the same ATM PW payload must be configured with the same SAP aggregation group group-id.

All common access configuration parameters, such as accounting, statistics, and packet layer QoS profile can be configured under the sap-aggregation-group.

Each sap-aggregation-group SAP has its own ingress and egress Layer 2 traffic descriptors. These descriptors are used for policing at ingress and shaping and scheduling priority at egress.

This command configures a SAP and associates the SAP as a member of a specified SAP aggregation group. The aggregation group must be configured before the SAP. The SAP must be associated with the aggregation group at the time of configuration. See sap-aggregation-group for more information.

Up to 16 SAPs can be bound to a SAP aggregation group.

The following restrictions apply to the SAP.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP are also deleted.

This command configures the circuit emulation service parameters. In the epipe context, circuit emulation parameters are configured to encapsulate TDM services using Epipes according to the MEF 8 standard.

This command is blocked for all SAPs except for E1, DS1, E3, DS3,and n × 64 kb/s channels configured for encap-type cem.

This command enables or disables asymmetric delay control on the Cpipe. When enabled, the TDM PW is analyzed and adjusted for asymmetric delay when the service is initially started or restarted. The service is considered to be down during this period.

The optional min-repeat keyword sets the analysis to repeat at configured time intervals after the service is up. The service remains up while the repeated analysis runs.

Asymmetric delay control must be enabled on both ends of the Cpipe; otherwise, a service parameter mismatch state occurs and the service is brought down.

This command enables the context to configure packet parameters on the SAP.

This command defines the size of the receive jitter buffer for the circuit emulation service SAP.

If asym-delay-control is enabled, the jitter buffer size must match on both ends of the Cpipe; otherwise, a service parameter mismatch state occurs and the service is brought down.

This command defines the payload size, in bytes, for one circuit emulation service packet.

This command defines the Emulated Circuit Identifier to be used for the (local) source end of the MEF 8 Epipe.

The no form of the command removes the ECID value from the service configuration.

This command defines the Emulated Circuit Identifiers to be used for the remote (destination) end of the MEF 8 Epipe.

The no form of the command removes the ECID value from the service configuration.

This command defines the destination IEEE MAC address to be used to reach the remote end of the MEF 8 Epipe.

This command enables or disables alarm reporting for CES circuit alarm conditions.

This optional command inserts RTP headers operating in absolute mode into the CES packets. If asym-delay-control is enabled, this command cannot be enabled for Cpipes.

The no form of this command will not insert RTP headers into CES packets.

This command enables the context to configure egress QoS policies for a SAP or a SAP aggregation group.

If no SAP egress QoS policy is defined, the system default SAP egress QoS policy is used for egress processing.

This command enables the context to configure ingress QoS policies for a SAP or a SAP aggregation group.

If no SAP ingress QoS policy is defined, the system default SAP ingress QoS policy is used for ingress processing.

This command sets the aggregate rate limits (PIR and CIR) for the SAP. The agg-rate sets the PIR value. The cir-rate sets the CIR value. When aggregate rate limits are configured on a second-generation (Gen-2) Ethernet adapter card, the scheduler mode must be set to 16-priority. On a third-generation (Gen-3) Ethernet adapter card, the scheduler mode is always 4-priority. For information on adapter card generations, refer to the “Evolution of Ethernet Adapter Cards, Modules, and Platforms” section in the 7705 SAR OS Interface Configuration Guide.

Configuring the cir-rate is optional. If a cir-rate is not entered, then the cir-rate is set to its default value (0 kb/s). If a cir-rate has been set and the agg-rate is changed without re-entering the cir-rate, the cir-rate automatically resets to 0 kb/s. For example, to change the agg-rate from 2000 to 1500 while maintaining a cir-rate of 500, use the command agg-rate-limit 1500 cir 500.

If the specified SAP is a LAG SAP, then agg-rate and cir-rate can be configured regardless of the scheduler mode setting on Gen-2 or Gen-3 hardware—it is not configurable if one of the ports configured in the LAG SAP is on Gen-1 hardware. If the active port is on a Gen-3 card or platform, then agg-rate and cir-rate are applicable. If the active port is on a Gen-2 card or platform, then agg-rate and cir-rate apply when the scheduler mode is set to 16-priority. If the active port is on a Gen-1 card, then agg-rate and cir-rate are not applicable. For details on the behavior of a mix-and-match LAG SAP, refer to the “LAG Support on Third-Generation Ethernet Adapter Cards, Ports, and Platforms” and “Network LAG Traffic Management” sections in the 7705 SAR OS Interface Configuration Guide.

Note: From Release 7.0.R6, schedulers on Gen-3 adapter cards and platforms have been updated to better align with the scheduling behavior supported on the other 7705 SAR adapter cards and platforms. The updated scheduler mode is called “4-priority” scheduler-mode throughout the CLI. Prior to Release 7.0.R6, the CLI designation was “4-priority-hqos”. In the updated mode of operation, arbitration among different flows at the second-tier aggregate (per-SAP or per-VLAN) and third-tier aggregate (per-customer (MSS)) levels are carried out in a round-robin manner, scheduling cir-rate first from the shapers, followed by the pir-rate.

Caution: Any Gen-3 adapter card or platform running Release 7.0.R6 or later software uses 4-priority scheduling instead of 4-priority-hqos scheduling, which was supported previously. The migration of scheduler mode is automatic with an upgrade and there is no operator action required. As part of the migration, all CIR values at second-tier (per-SAP and per-VLAN) and third-tier (per-customer (MSS)) aggregate shaper levels are set to zero. Operators must exercise caution when performing an upgrade to Release 7.0.R6 or later from a previous Release 7.0 version, and must adjust the affected CIR values in accordance with the needs of their applications as soon as possible.

The no form of the command sets the agg-rate to the maximum and the cir-rate to 0 kb/s.

This command associates an IP filter policy with an ingress Epipe or Ipipe SAP.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message will be displayed.

The no form of the command removes any configured filter ID association with the SAP. The filter policy cannot be deleted until it is removed from all SAPs where it is applied.

This command specifies which dot1q tag position (top or bottom) in a qinq-encapsulated packet should be used when QoS evaluates dot1p classification.

The no form of the command restores the default dot1p evaluation behavior for the SAP, which means that the inner (bottom) tag (second tag) dot1p bits are used for classification.

By default, the dot1p bits from the inner tag service-delineating dot1q tag are used.

Table 42 shows which set of dot1p bits are used for QoS purposes when match-qinq-dot1p is configured. To use the table, find the row that represents the settings for Port/SAP Type and Match-QinQ-Dot1q Setting. Use the Existing Packet Tags column to identify which dot1q tags are available in the packet. Then use the P-bits Used for Match column to identify which dot1q tag contains the dot1p bits that are used for QoS dot1p classification.

When enabled, the qinq-mark-top-only command specifies which P-bits to mark during packet egress. When disabled, both sets of P-bits are marked. When enabled, only the P-bits in the top Q-tag are marked. The no form of the command is the default state (disabled).

Table 43 shows the dot1p re-marking behavior for different egress port type/SAP type combinations and qinq-mark-top-only state, where “False” represents the default (disabled) state.

If a new tag is pushed, the dot1p bits of the new tag will be zero (unless the new tag is re-marked by the egress policy. The dot1p bits are configured using the dot1p parameter under the config>qos context.

This command associates a QoS policy with an ingress or egress for a SAP or a SAP aggregation group.

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

For SAPs, the qos command is used to associate both ingress and egress QoS policies on a per-SAP basis. The qos command only allows ingress policies to be associated on the SAP ingress and egress policies on the SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

For SAP aggregation groups, the qos command is used to apply an ingress and egress QoS policy to each N > 1 service. The configuration of a QoS policy on a per-SAP basis is not permitted. Any existing QoS profile can be applied to the N > 1 service. The QoS policy governs the whole PW service at the packet layer, irrespective of the number of SAPs that are bound to the N > 1 service.

For SAPs that are bound to an aggregation group, VC-based QoS using Layer 2 traffic descriptor profiles can be applied at ingress and egress. See the traffic-desc command for more information.

Only one ingress and one egress QoS policy can be associated with a SAP or a SAP aggregation group at one time.

By default, no specific QoS policy is associated with the SAP or SAP aggregation group for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP or SAP aggregation group, and the QoS policy reverts to the default.

This command sets the scheduler mode for the SAP and is part of the hierarchical QoS (H-QoS) feature on the 7705 SAR.

If the mode is 4-priority, then the SAP is considered an unshaped 4-priority SAP and the agg-rate-limit cannot be changed from its default values.

If the mode is 16-priority and the agg-rate limit parameters are configured to be non-default values, then the SAP is considered a shaped SAP. If the agg-rate limit parameters are left in their default settings, the SAP is considered an unshaped, 16-priority SAP.

This command is blocked on third-generation (Gen-3) Ethernet adapter cards and platforms, such as the 6-port Ethernet 10Gbps Adapter card and the 7705 SAR-X, which only support 4-priority scheduling mode.

If the specified SAP is a LAG SAP, scheduler-mode can be configured but is not applied to Gen-3 adapter cards and platforms. If one of the ports in the LAG is on a Gen-1 adapter card, then scheduler-mode cannot be configured.

This command applies a shaper group to a SAP. The shaper group must already be created and must be within the shaper policy assigned to the Ethernet MDA (for ingress) or port (for egress). A shaper group is a dual-rate aggregate shaper used to shape aggregate access ingress or egress SAPs at a shaper group rate. Multiple aggregate shaper groups ensure fair sharing of available bandwidth among different aggregate shapers.

The default shaper group cannot be deleted.

The no form of this command removes the configured shaper-group.

This command enables the context to configure microwave link parameters for an Epipe SAP in a Microwave Awareness mixed link scenario. See Configuring Epipe SAP Microwave Link Parameters for Interworking with TDM2Ethernet for more information.

This command configures the TDM2 Ethernet compression on an Epipe SAP that is using a microwave link.

The no form of the command removes any configured TDM2 Ethernet compression associated with the Epipe SAP.

This command creates the accounting policy context that can be applied to a SAP or SAP aggregation group. An accounting policy must be defined before it can be associated with a SAP or SAP aggregation group. If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP or SAP aggregation group at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association from the SAP or SAP aggregation group, and the accounting policy reverts to the default.

This command enables accounting and statistical data collection for the SAP or SAP aggregation group. When applying accounting policies, the data, by default, is collected in the appropriate records and written to the designated billing file.

When the no collect-stats command is issued, the statistics are still accumulated by the CSM. However, the CPU will not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued, the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

This command binds a service to an existing Service Destination Point (SDP). The syntax for an Epipe spoke SDP has additional parameters. See spoke-sdp for the Epipe syntax.

A spoke SDP is treated as the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke SDPs or SAPs) and not transmitted on the port on which it was received.

The SDP has an operational state that determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with a service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end 7705 SAR devices can participate in the service.

The endpoint command allows multiple spoke SDPs to be associated with the endpoint, providing PW redundancy capability. The endpoint must be defined using the create command before multiple spoke SDPs can be associated with the endpoint. The no-endpoint command removes the endpoint and the spoke SDP associations.

On Cpipe spoke SDPs, you can configure icb to provide resiliency by reducing packet loss when an active endpoint is switched from a failed node of an MC-APS group to a standby node. For example, if a port on an active MC-APS node fails, the port on the peer becomes active, but traffic continues to route to the previously active MC-APS node until it detects the failure. ICB spoke SDPs ensure that in-flight packets are delivered to the newly active MC-APS node. Two ICB spoke SDPs must be created. The ICB associated with the MC-APS on the first node must be associated with the pseudowire on the second node. Likewise, the ICB associated with the MC-APS on the second node must be associated with the pseudowire on the first node.

The no form of the spoke-sdp command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

This command binds an Epipe service to an existing Service Destination Point (SDP). The syntax for an Apipe, Cpipe, or Ipipe spoke SDP has additional parameters. See spoke-sdp for the Apipe, Cpipe, or Ipipe syntax.

A spoke SDP is treated as the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke SDPs or SAPs) and not transmitted on the port on which it was received.

The SDP has an operational state that determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with an Epipe service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end 7705 SAR devices can participate in the service.

The endpoint command allows multiple spoke SDPs to be associated with the endpoint, providing PW redundancy capability. The endpoint must already be defined in the config>service>epipe context in order to associate multiple spoke SDPs with the endpoint.

The icb (inter-chassis backup) spoke SDP provides resiliency by reducing packet loss when an active endpoint is switched from a failed node of an MC-LAG group to a standby node. For example, if a port on an active MC-LAG node fails, the port on the peer becomes active, but traffic continues to route to the previously active MC-LAG node until it detects the failure. ICB spoke SDPs ensure that in-flight packets are delivered to the newly active MC-LAG node. Two ICB spoke SDPs must be created. The ICB associated with the MC-LAG on the first node must be associated with the pseudowire on the second node. Likewise, the ICB associated with the MC-LAG on the second node must be associated with the pseudowire on the first node.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

This command configures the egress SDP context.

This command configures the ingress SDP context.

This command specifies the precedence of the spoke SDP when there are multiple spoke SDPs associated with one service endpoint. One SDP binding can be assigned to be the primary SDP binding, leaving three bindings for secondary bindings, or, if no primary spoke SDP is defined, up to four secondary spoke SDPs can be configured. When an SDP binding goes down, the next highest precedence SDP binding will begin to forward traffic.

The no form of the command returns the precedence value to the default.

This command enables pseudowire status signaling for spoke SDPs. The no form of this command disables pseudowire status signaling. When pseudowire status signaling is disabled, a 7705 SAR does not include the PW status TLV in the initial label mapping message of the pseudowire that is used for a spoke SDP. This forces both 7705 SAR PEs to use the pseudowire label withdrawal method for signaling pseudowire status.

If pseudowire status signaling is enabled, the 7705 SAR includes the pseudowire status TLV in the initial label mapping message for the pseudowire.

This command configures the egress VC label.

This command configures the ingress VC label.

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command

This command specifies the IP address of the CE device associated with an Ipipe SAP or spoke SDP. In the case of a SAP, it is the address of the CE device directly attached to the SAP. For a spoke SDP, it is the address of the CE device reachable through that spoke SDP (for example, attached to the SAP on the remote node). The address must be a host address (no subnet addresses are accepted) as there must be only one CE device attached to an Ipipe SAP. The CE address specified at one end of an Ipipe will be used in processing ARP messages at the other endpoint, as the router acts as a proxy for ARP messages.

This command indicates whether the control word is used or not. The value of the control word is negotiated with the peer.

This command is mandatory for SAToP and CESoPSN encapsulation.

The control word must be used for any pseudowire service that transports packets that are less than 64 bytes. When the control word is enabled and the packet length is less than 64 bytes (that is, the length of the Layer 2 payload plus the length of the control word), the length field in the control is set to the length of the packet. The CE-bound PE uses the length field in the control word to determine the size of the padding that was added by the PSN so that the PE can extract the PW payload from the PW packet.

Note: If the control word is not set, the PE cannot determine the original length of the packet and will forward the payload, including the padding bits. On reception of the padded packet, the CE will drop the packet. See RFC 4385 for more information.

This command enables the context to provide access to the various options that control the termination of ATM cell concatenation into an MPLS frame. Several options can be configured simultaneously. The concatenation process for a given MPLS packet ends when the first concatenation termination condition is met. The concatenation parameters apply only to ATM N-to-1 cell mode VLL.

Frame boundaries are not configurable.

This command enables the configuration of CLP change to be an indication to complete the cell concatenation operation.

The no form of the command resets the configuration to ignore the CLP change as an indication to complete the cell concatenation.

This command enables the configuration of the maximum number of ATM cells to accumulate in an MPLS packet. The remote peer will also signal the maximum number of concatenated cells it is willing to accept in an MPLS packet. When the lesser of the configured value and the signaled value is reached, the MPLS packet is queued for transmission onto the pseudowire. It is ensured that the MPLS packet MTU conforms to the configured service MTU.

If the max-delay and jitter buffer options are not configured, then the maximum number of cells allowed in a single VLL frame must be less than the configured service-mtu size.

The no form of this command sets max-cells to the value “1”, indicating that no concatenation will be performed.

This command enables the configuration of the maximum amount of time to wait while performing ATM cell concatenation into an MPLS packet before transmitting the MPLS packet. This places an upper bound on the amount of delay introduced by the concatenation process. When this amount of time is reached from when the first ATM cell for this MPLS packet was received, the MPLS packet is queued for transmission onto the pseudowire.

The no form of this command resets max-delay to its default value.

This command enables access to the context to configure ATM-related attributes. This command can only be used when a given context (for example, a channel or SAP) supports ATM functionality such as:

If ATM functionality is not supported for a given context, the command returns an error.

This command provides access to the context to configure egress ATM traffic policies for the SAP.

This command provides access to the context to configure ingress ATM traffic policies for the SAP.

This command assigns an ATM traffic descriptor profile to a SAP.

When configured under the ingress context, the specified traffic descriptor profile defines the traffic contract in the forward direction. When configured under the egress context, the specified traffic descriptor profile defines the traffic contract in the backward direction.

For SAPs that belong to a SAP aggregation group, the egress traffic descriptor can be changed. The ingress traffic descriptor cannot be changed from the default (1). Attempting to change the ingress traffic descriptor will cause an error message to be displayed.

The no form of the command reverts to the default traffic descriptor profile.

This optional command is used only with SAPs that are configured as members of a SAP aggregation group.

The vcid-translation command is used when traffic arrives on multiple SAPs within the same SAP aggregation group with the same VPI/VCI value. In this case, the VPI/VCI values for incoming ATM cells that are to be aggregated in a single ATM PW must be translated to preserve their individual identification before the cells are mapped to the ATM PW payload.

When vcid-translation is configured for a SAP, ingress cells have their VPI/VCI values translated (rewritten) to the vcid-translation value. On the same node, egressing cells have their VPI/VCI values translated back to the VPI/VCI of the SAP.

If the vcid-translation for any ATM sap-aggregation-group SAP is not configured, the ingress VPI/VCI values are retained.

The 7705 SAR performs a check to ensure the uniqueness of the translated VPI/VCI values for all of the SAPs of the same ATM PW service, that is, within the same SAP aggregation group. If there are duplicate VC identifiers, the status of the VCs are set to operationally down and flagged as ApipeSapVcIdNotUnique.

It is the responsibility of the user to ensure uniqueness of the VPI and VCI values after translation.

This command enables the context to configure OAM functionality for a PVCC delimiting a SAP.

The T1/E1 ASAP Adapter cards and 4-port OC3/STM1 Clear Channel Adapter card support the generation of F4 (VP) and F5 (VC) AIS cells when the Apipe service is operationally down. When the Apipe service is operationally up, OAM cells are transported over the Apipe and are transparent to the 7705 SAR. This capability is in accordance with ITU-T Recommendation I.610 - B-ISDN Operation and Maintenance.

This command configures AIS/RDI fault management on a PVCC. Fault management allows PVCC terminations to monitor and report the status of their connection by propagating fault information through the network and by driving the PVCC operational status.

The 7705 SAR Apipe does not support PVCC terminations. Instead, it allows OAM cells to be transported transparently from end-to-end. When this command is enabled, AIS cells are generated when an Apipe or corresponding SAP is operationally down.

The no command disables alarm-cells functionality for the Apipe. When alarm-cells functionality is disabled, AIS cells are not generated as result of the Apipe or corresponding SAP going into the operationally down state.