Service entities

The encapsulation type is an access property of a service Ethernet port or SONET/SDH or TDM channel. The appropriate encapsulation type for the port or channel depends on the requirements to support multiple services on a single port or channel on the associated SAP and the capabilities of the downstream equipment connected to the port or channel. For example, a port can be tagged with IEEE 802.1Q (referred to as dot1q) encapsulation in which each individual tag can be identified with a service. A SAP is created on a specific port or channel by identifying the service with a specific encapsulation ID.

The following lists encapsulation service options on Ethernet ports:

• null

  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. The encapsulation ID is always 0 (zero).

• dot1q

  Dot1q supports multiple services for one customer or services for multiple customers (7750 SR/7950 XRS service access point (SAP) and 7750 SR/7950 XRS and 7450 ESS multiple SAPs on a single port/channel). For example, the port is connected to a multitenant unit (MTU) device with multiple downstream customers. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.

• QinQ

  The QinQ encapsulation type adds a IEEE 802.1Q tag to the 802.1Q tagged packets entering the network to expand the VLAN space by tagging tagged packets, producing a double tagged frame.

On dot1q-encapsulated ports where a default SAP is configured, all packets with q-tags not matching any explicitly defined SAPs are assigned to this SAP. SAPs with default QinQ encapsulation are supported in VPLS, Epipe, IES and VPRN services. Both DHCP snooping and IGMP snooping are supported for QinQ SAPs. In this context, the character ‟*” indicates ‟default” which means ‟allow through”. A 0 value allows the Q-tag to be missing.

One of the applications where this feature can be applicable is an access connection of a customer who uses the whole port to access Layer 2 services. The internal VLAN tags are transparent to the service provider. This can be provided by a null encapsulated port.

A dedicated VLAN (not used by the user) can be used to provide CPE management.

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

There a few constraints related for the use of default SAP on a Dot1q-encapsulated port:

• This type of SAP is supported only on VPLS and Epipe services and cannot be created in IES and VPRN services as it 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. This would require remembering VLAN tags per hosts. By not allowing IGMP snooping of this SAP, all IGMP packets are transparently forwarded.

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

In a Dot1q port SAP with a non-zero or non-default tag, the tag (referred to as service-delimiting tag) is stripped off on ingress and pushed on egress. For example, the tag is popped from frames received on SAP 1/1/1:10 with a tag that contains VID 10. A tag with VID 10 is pushed onto frames that are sent out of SAP 1/1/1:10.

In case of Dot1q port SAPs with a zero or default tag, no tag is stripped off on ingress, and no tag is pushed on egress. For instance, tags are not stripped off from frames entering 1/1/1:* or 1/1/1:0, and tags are not pushed either on frames egressing those SAPs.

A QinQ SAP has the following format:

qinq <port-id | lag-id>:<qtag1 | cp-conn-prof-id>

Where:

• qtag1 is the outer Q-tag value - [*, null, 0 to 4094]

• qtag2 is the inner Q-tag value - [*, null, 0 to 4094]

• cp: keyword
• conn-prof-id: 1 to 8000

Regular QinQ SAPs have qtag1 and qtag2 values between 1 and 4094. In addition, QinQ Ethernet and LAG ports support the additional ‟default” SAPs. Use the following command to enable default SAPs for QinQ Ethernet and LAG ports:

• MD-CLI

  configure service system extended-default-qinq-sap-lookup

• classic CLI

  configure system ethernet new-qinq-untagged-sap

QinQ Ethernet and LAG ports support these additional ‟default” SAPs:

• ‛*.null’ is defined as a default sap for singly-tagged frames in a QinQ port. This SAP accepts single tags in the range 0 to 4095 as well as untagged traffic. This SAP never pushes any tags on egress.

• ‛*.*’ is defined as a default sap for doubly-tagged frames in a QinQ port. This SAP accepts untagged, singly tagged, and doubly tagged frames with tags in the range 0..4095. This SAP never pushes any tags on egress.

• ‛null.null’ is defined as a default SAP for untagged frames only in a QinQ port. This SAP accepts only untagged frames and never pushes any tags on egress. This SAP has higher priority than ‛*.null’ or ‛*.*’, or both, when configured on the same QinQ port, therefore it captures untagged frames even if ‛*.null’ or ‛*.*’ are configured.

• ‛0.*’ can also be used as a default SAP and captures untagged frames, doubly-tagged frames with qtag1 0 (and any value on qtag2) and singly-tagged frames with Q-tag 0. SAP ‛0.*’ and ‛null.null’ cannot be configured on the same QinQ port.

• In addition to the above-mentioned SAPs, qtag2 can also be '0' or '*' when qtag1 is an explicit value in the 1 to 4094 range, for instance: 1/1/1:10.0 or 1/1/1:10.*. Assuming qtag1 is the same value, qtag1.* and qtag1.0 are supported in the same QinQ port. The system never pushes any qtag2 on egress for 1/1/110.0 and 1/1/1:10.*, only qtag1 is pushed. The x.0 accepts only 0 as second tag or not tag (and nothing else), while x.* accepts anything as second tag or no tag.

A SAP lookup is performed when a new frame arrives to a QinQ port. This 'lookup' is based on the <outer-tag, inner-tag> values of the frame.

You can control the forwarding of packets on a QinQ X.0 access SAP to only accept frames with a single tag matching the SAP outer tag or frames with double tags where the outer tag matches the SAP outer tag and the inner tag is set to 0. System/port settings (QinQ x.0 access SAP control enabled) shows the SAP lookup precedence order for incoming frames with <qtag1.qtag2> Q-tag values when this option is enabled.

The following considerations apply to the information described in System/port settings (QinQ x.0 access SAP control enabled):

• All SAP types (:X.Y, :X.0, :X.*, :0.* or :null.null, :*.null and :*.*) are supported in the same QinQ port (with the exception of :0.* and :null.null being incompatible) and, in the table, they are ordered from the most specific (left side) to the least specific with the following VID matching ranges:

  • X or Y means <1 to 4094>

  • * means <0 to 4095> or untagged

  • null means 'no tag'

  • 0 means VID 0 or untagged

• On egress, the system pushes a tag with a VID value for X and Y, whereas no tag is pushed on egress for values 0, * or null. For example:

  • On SAP 1/1/1:10.20, the system pushes tags with VIDs 10 and 20 (outer and inner respectively) on egress.

  • On SAP 1/1/1:10.0 or 1/1/1:10.* the system pushes only one tag with VID 10 on egress.

  • On SAPs 1/1/1:0.*, 1/1/1:null.null, 1/1/1:*.null or 1/1/1:*.* the system never pushes any tags on egress.

• The user can decide the SAP types that are configured in a specific port. Not all SAP types must be configured in a port.

• System/port settings (QinQ x.0 access SAP control enabled) shows the lookup behavior for ingress frames and priority across SAPs in case more than one can match a specific ingress frame. The SAP lookup result for a specific frame does not depend on the operational status of the SAP. For instance:

  • In a port with SAPs 1/1/1:0.* and 1/1/1:*.* defined, the SAP lookup for a specific frame with VIDs (0, 300) yields SAP 1/1/1:0.* regardless of its operational status.

  • The frame only matches SAP 1/1/1:*.* when the 0.* SAP is removed from the configuration.

• The following applies to VLAN tag handling:

  • The system does not strip-off any tags for frames entering the default SAPs (:0.*, :null.null, :*.null or :*.*).

  • No extra tags are added when the system transmits frames on the default SAPs (:0.*, :null.null, :*.null or :*.*).

The following examples illustrate the SAP classification QinQ ports. The examples assume that QinQ x.0 access SAP control is enabled.

As shown in Example 1 SAP classification QinQ ports, assuming that QinQ x.0 access SAP control is enabled, the following SAPs are defined on the same port:

• 1/1/1:3000.1001 - business customer - vpls-1

• 1/1/1:2000.1002 - business customer - vpls-2

• 1/1/1:20.0 - BNG traffic - vpls-3

• 1/1/1:20.* - business customer - epipe-4

• 1/1/1:0.* - business customer - epipe-5

• 1/1/1:*.null - wholesaling single tag - epipe-6

• 1/1/1:*.* - wholesaling double tag - epipe-7

Based on the SAPs configuration described above, the incoming traffic is classified in the following way - notation (outer-VID, inner-VID):

• (3000, 1001) goes to vpls-1

• (20) goes to BNG (vpls-3)

• (20, 0) goes to BNG (vpls-3)

• (20, 10) goes to epipe-4

• untagged, (0), (0, 0), and (0, 10) go to epipe-5

• (500) goes to wholesaling single tag (epipe-6)

• (500, 300) and (500, 0) go to wholesaling double tag (epipe-7)

Example 2 SAP classification QinQ ports highlights how untagged, VID=0 tagged frames and 20.X frames are classified in the absence of the 0.* and 20.* SAPs.

As described in Example 2 SAP classification QinQ ports, assuming QinQ x.0 access SAP control is enabled, the following SAPs are defined on the same port:

• 1/1/1:3000.1001 - business customer - vpls-1

• 1/1/1:2000.1002 - business customer - vpls-2

• 1/1/1:20.0 - BNG traffic - vpls-3

• 1/1/1:*.null - wholesaling single tag - epipe-6

• 1/1/1:*.* - wholesaling double tag - epipe-7

Incoming traffic - notation (outer-VID, inner-VID)

• (3000, 1001) goes to vpls-1

• (20) goes to BNG (vpls-3)

• (20, 0) goes to BNG (vpls-3)

• (20, 10) goes to wholesaling double tag (epipe-7)

• untagged and (0) go to wholesaling single tag (epipe-6)

• (500) goes to wholesaling single tag (epipe-6)

• (500, 300) and (500, 0) go to wholesaling double tag (epipe-7)

• (0,0), and (0,10) goes to wholesaling double tag (epipe-7)

The following constraints must be considered when configuring default QinQ SAPs (:0.*, :null.null, :*.null, :*.*):

• Only supported in Ethernet ports or LAG.

• Only supported on Epipe, PBB-Epipe, VPLS and I-VPLS services. They are not supported on VPRN, IES, R-VPLS or B-VPLS services.

• Capture SAPs with encapsulation :*.* cannot coexist with a default :*.* SAP on the same port.

• Inverse-capture SAPs (*.x) are mutually-exclusive with :*.null SAPs.

• *.null SAPs are not supported for Open Flow matching and forwarding.

• The following applies to Eth-CFM:

  • Primary VLAN is not supported.

  • Eth-CFM extractions occur within the service after the packet lookup has determined which service the inbound packet belongs to.

  • All four SAPs (null.null, *.null, *.* and 0.*) are treated equally by ETH-CFM. Only untagged CFM PDUs are extracted by a local MEP or MIP. Additional tags in the header may match the service context but are not extracted by ETH-CFM for processing.

  • ETH-CFM PDU transmission encapsulation is based on the SAP configuration. This means that the ETH-CFM PDUs are transmitted out all four of these SAPs untagged. Care must be taken to ensure that there is no downstream service that may intercept the ETH-CFM PDUs that are not intended for that service. See System/port settings (QinQ x.0 access SAP control enabled) for a description of the SAP lookup precedence order for incoming frames and to understand the potential consequences.

• Default QinQ SAPs do not support the following features:

  • PW-SAPs

  • Eth-tunnel or eth-ring SAPs

  • VLAN-translation copy-outer

  • E-Tree root-leaf-tag SAPs

  • Subscriber-management features

  • BPDU-translation

  • Eth-tunnels

  • IGMP-snooping

  • MLD-snooping

The services and SAP encapsulations are listed in Service and SAP encapsulations.

When configuring a SAP, consider the following:

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

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

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

• When a SAP is deleted, all configuration for the SAP is also deleted. For Internet Enhanced Service (IES), the IP interface must be shut down before the SAP on that interface may be removed.

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

• A port or channel with a dot1q encapsulation type means 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 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 or channel is administratively shutdown, all SAPs on that port or channel are operationally out of service.

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

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

  • ingress filter policy

  • egress filter policy

  • ingress QoS policy

  • egress QoS policy

  • accounting policy

  • ingress scheduler policy

  • egress scheduler policy

Ethernet ring protection switching offers ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks. G.8032 (Ethernet-ring) is built on Ethernet OAM and often referred to as Ring Automatic Protection Switching (R-APS).

For further information about Ethernet rings, see G.8032 Ethernet ring protection switching.

This feature provides a bandwidth Connection Admission Control (CAC) function per port or LAG based on an administrator bandwidth configured on a SAP and on the associated port or LAG. A booking factor is provided to allow overbooking or underbooking of the sum of the SAP bandwidth compared to the port or LAG bandwidth.

The administrator bandwidth is a statically configured abstract value that could represent either the ingress or egress bandwidth, or both.

The goal of the CAC function is to ensure that the sum of the administrator SAP bandwidth on a port or LAG does not exceed the administrator bandwidth configured on that port or LAG.

This feature is supported on all service Ethernet SAPs, excluding PW SAPs, Ethernet tunnels and subscriber group interface SAPs. It is not supported in a VPLS or Epipe SAP template. It is applicable to both access and hybrid ports or LAGs; in the case of a hybrid port or LAG, the SAP CAC bandwidth only applies to the access operation.

By default, a SAP, port, or LAG has no administrator bandwidth configured, in which case it is excluded from the CAC function. Configuring an administrator bandwidth on a SAP enforces the CAC function.

An administrator bandwidth can only be configured on a SAP that is connected to a port or LAG on which an administrator bandwidth is already configured. When a LAG is configured, the administrator bandwidth and booking factor on its constituent ports are ignored.

The system tracks the requested and available bandwidth per port or LAG, where the available bandwidth is equal to the administrator bandwidth on the port or LAG, with the booking factor applied, minus the sum of administrator bandwidth configured on its SAPs. An attempt to increase a SAP's administrator bandwidth fails if there is insufficient available bandwidth on its port or LAG.

Use the following commands to configure the administrator bandwidth and booking factor for the port or LAG.

configure lag access bandwidth
configure lag access booking-factor

configure port ethernet access bandwidth
configure port ethernet access booking-factor 

configure service {epipe | ipipe | vpls} sap bandwidth
configure service {ies | vprn} interface sap bandwidth 

Dynamic changes in administrator bandwidth and booking factor are possible without having to disable the SAP, port, or LAG.

A SAP is allocated bandwidth on a port or LAG regardless of whether the SAP and port or LAG are administratively or operationally up or down. The administrator bandwidth must be removed from the SAP configuration to free up its bandwidth on the port or LAG. Actions such as clearing the card or MDA, power cycling the card, or removing and reinserting a card or MDA do not change the CAC state of the SAP and port or LAG.

SAP lookup matching order for dot1q ports describes the SAP lookup matching order that is applied when a CP SAP is used in dot1q ports.

SAP lookup matching order for QinQ ports (QinQ x.0 access SAP control enabled) describes the SAP lookup matching order that is applied when CP SAPs is used in QinQ ports.

The following considerations apply when connection profile VLAN (CP VLAN) is used in QinQ ports:

• A CP can be defined for inner or outer tags but not both at the same time; for example, ‟:X.CP” and ‟:CP.*” are possible, but not ‟:CP.CP”.

• It is important to note that ‟:CP:Y” is not allowed; for example, if a CP is defined at the outer VID, the inner VID can only be a ‟*” or a ‟0”.

• ‟:0.CP” SAPs are not allowed; if the outer VID is 0, the inner VID cannot be a connection-profile-vlan value.

• A CP cannot contain a VID that is associated with an explicitly defined inner or outer tag in a specific port. For example, assuming that X and Y are tags defined in ‟CP”, a specific port can be defined with ":X.CP" or ":Y.CP", but not with ":X.Y" and ":X.CP" or ":CP.*" and "X.*" in the same port.

• The following combinations are allowed:

  • :CP.0 (matches frames with outer tags contained in CP and inner tags 0 or null)

  • :CP.* (matches frames with outer tags contained in CP and any inner tags)

• In the case where a VLAN tag combination matches different SAPs, the highest priority SAP is picked, irrespective of its oper-status, as long as the SAP is still created. Therefore, if the SAP is down, the frames do not go to a different SAP. For example, suppose that ingress frames with VIDs 10.25 are classified as part of sap 10.cp-1. Only when sap 10.cp-1 is removed from the configuration do the frames with VIDs 10.25 go to sap cp-1.*.

To configure a distributed service from ALA-A to ALA-B, the SDP ID (1) (shown in GRE service distribution point (SDP) pointing from ALA-A to ALA-B) must be specified in the service creation process 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 from ALA-B to ALA-A, the SDP ID (5) must be specified.

When an SDP is bound to a service, it is bound as either a spoke SDP or a mesh SDP. The type of SDP indicates how flooded traffic is transmitted.

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

All mesh SDPs bound to a service are logically treated like a single bridge ‟port” for flooded traffic where flooded traffic received on any mesh SDP on the service is replicated to other ‟ports” (spoke SDPs and SAPs) and not transmitted on any mesh SDPs.

SDP is enhanced to use BGP route tunnel to extend inter-AS support for routes and services. An SDP can be configured based on service transport method (for example, GRE or MPLS tunnel). MPLS SDP support is enhanced to allow a BGP route tunnel to reach the far-end PE.

A single method of tunneling is allowed per SDP (for example, LDP, RSVP-TE LSP or BGP route tunnel).

For the inter-AS far-end PE, next-hop for BGP route tunnel must be one of the local ASBR. The LSP type selected to reach the local ASBR (BGP labeled route next-hop) must be configured under the BGP global context. LDP must be supported to provide transport LSP to reach the BGP route tunnel next-hop.

Only BGP route labels can be used to transition from ASBR to the next-hop ASBR. The global BGP route tunnel transport command option must be entered to select an LSP to reach the PE node from ASBR node. On the last BGP segment, both BGP and LDP and LDP routes may be available to reach the far-end PE from the ASBR node. LDP LSP must be preferred because of higher protocol priority. This leads to just one label besides other labels in stack to identify VC or VPN at far-end PE nodes.

SDP keepalives actively monitor the SDP operational state using periodic Nokia SDP ping echo requests and echo reply messages. Nokia SDP ping is a part of the Nokia suite of service diagnostics built on a Nokia service-level OAM protocol. When the SDP ping is used in the SDP keepalive application, the SDP echo requests and echo reply messages are a mechanism for exchanging the far-end SDP status.

Configuring SDP keepalives on an SDP is optional. SDP keepalives have the following configurable parameters:

• admin up/admin down state

• hello time

• message length

• max drop count

• hold down time

SDP keepalive echo request messages are only sent when the SDP is completely configured and administratively up, and SDP keepalives are administratively up. If the SDP is administratively down, keepalives for the SDP are disabled.

SDP keepalive echo request messages are sent out periodically based on the configured hello time. Message lengths for echo requests are configurable. If max drop count echo request messages do not receive an echo reply, the SDP immediately becomes operationally down.

If a keepalive response is received that indicates an error condition, the SDP immediately becomes operationally down.

When a response is received that indicates the error has cleared and the hold down time interval has expired, the SDP is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP enters the operational state.

This feature introduces the support of SDP administrative groups, referred to as SDP admin groups. SDP admin groups provide a way for services using a pseudowire template to automatically include or exclude specific provisioned SDPs. SDPs sharing a specific characteristic or attribute can be made members of the same admin group.

The following command creates the admin groups that are to be used by SDPs on this node:

configure service sdp-group group-name

A maximum of 32 admin groups can be created. The group can only be disabled if the group-name is not referenced in a PW template or SDP.

The group value ranges from zero (0) to 31. It is uniquely associated with the group name at creation time. If the user attempts to configure another group name for a group value that is already assigned to an existing group name, the SDP admin group creation is failed. The same happens if the user attempts to configure an SDP admin group with a new name but associates it to a group value already assigned to an existing group name.

The following command configures the SDP membership in admin groups:

configure service sdp sdp-group

The user can enter a maximum of one (1) admin group name at once. The user can execute the command multiple times to add membership to more than one admin group. The admin group name must have been configured or the command is failed. Admin groups are supported on an SDP of type GRE and of type MPLS (BGP/RSVP/LDP). They are also supported on an SDP with the mixed LSP mode command option enabled.

The following commands select which admin groups to include or exclude in a pseudowire template:

configure service pw-template sdp-include
configure service pw-template sdp-exclude

The admin group name must have been previously configured or the command fails. The user can execute the command multiple times to include or exclude more than one admin group. These commands can only be used when the SPF is provisioned to use or prefer when the PW template is created. If the same group name is included and excluded within the same PW template, only the exclude option is enforced.

Any changes made to the admin group SDP include and exclude constraints are only reflected in existing spoke SDPs after the following command has been executed:

tools perform service eval-pw-template allow-service-impact

When the service is bound to the PW template, the SDP selection rules enforce the admin group constraints specified in the include and exclude commands.

configure service vpls bgp pw-template-binding

configure service epipe spoke-sdp-fec pw-template-bind

SDP admin groups can be enabled on all router services that make use of the pseudowire template (BGP-AD VPLS service, BGP-VPLS service, BGP-VPWS and FEC129 VLL service). In the latter case, SR OS provides support at the T-PE nodes only.

In the current SDP selection process, all provisioned SDPs with the correct far-end IP address, the correct tunnel-far-end IP address, and the correct service label signaling are considered. The SDP with the lowest admin metric is selected. If more than one SDP with the same lowest metric are found, then the SDP with the highest sdp-id is selected. The type of SDP, GRE or MPLS (BGP/RSVP/LDP) is not a criterion in this selection.

The selection rule with SDP admin groups is modified such that the following admin-group constraints are applied up front to prune SDPs that do not comply:

• If one or more SDP include statement is part of the PW template, then an SDP that is a member of one or more of the included groups is considered. With the sdp-include statement, there is no preference for an SDP that belongs to all included groups versus one that belongs to one or fewer of the included groups. All SDPs satisfying the admin-group constraint are considered and the selection above based on the lowest metric and highest SDP ID is applied.

• If one or more SDP exclude statement is part of the PW template, then an SDP that is a member of any of the excluded groups is not considered.

GRE-based SDPs over IPv6 transport support the exchange of service-related data between routers using IPv6, similar to IPv4-based GRE SDPs. The IPv6-based GRE SDPs are limited to spoke SDPs with static signaling. IPv6 based GRE SDPs currently support Epipe services.

To use this functionality, you must define an IPv6 system IP address that is reachable. The GRE-based SDPs over IPv6 use the system IP address as the source address of the GRE traffic and also as the termination point for the traffic from remote PE routers.

The following example shows a configuration for a GRE-based SDP over IPv6 transport.

[ex:/configure service]
A:admin@node-2# info
    sdp 11003 {
        admin-state enable
        signaling off
        keep-alive {
            hello-time 1
        }
        far-end {
            ip-address 3ffe::2828:2805
        }
    }

A:node-2>config>service# info
----------------------------------------------
        sdp 11003 create
            signaling off
            far-end 3ffe::2828:2805
            keep-alive
                shutdown
                hello-time 1
            exit
            no shutdown
        exit

GRE SDP tunnel fragmentation and reassembly allows those services for which fragmentation is typically not available to make use of IP layer fragmentation and reassembly of GRE SDP tunnels that carry those services. It enables services that require larger MTUs to be carried over network segments where the MTU is less than the MTU of their respective GRE SDP tunnel packets. As a result, GRE SDP tunnel packets that require fragmentation are either fragmented at the source node or within the MTU restricted network, and reassembled on the GRE SDP terminating node.

GRE SDP tunnel fragmentation is supported on the following platforms:

• VSR-I

• VSR-a

Use the following command to terminate GRE SDP tunnel packets directly on a router interface IP address:

• MD-CLI

  configure router interface gre-termination

• classic CLI

  configure router interface address gre-termination

This command is supported on the following platforms:

• VSR-I

• VSR-a

Services that support GRE SDP termination on the router interface IP address include the following:

• VPRN services (spoke SDP and auto-bind-tunnel)

• T-LDP signaled Ethernet VLL services

• T-LDP signaled VPLS services

• BGP-VPLS services

• BGP-VPWS services

Only GRE SDP tunnel packets that have a destination IP that is equal to the /31 value of the IP address configured on the router interface can terminate on the router interface. For example, if the address is set to 1.2.3.4/24, only the single /31 address 1.2.3.4 is used for the GRE SDP tunnel packet to terminate on. GRE SDP termination on router interface IP addresses is not supported on loopback interfaces.

When T-LDP is used to signal services, the local LSR ID command option must be set to the /31 value of the IP address of the router interface used to terminate the GRE SDP tunnel packets.

When BGP is used to advertise routes for services, the local address for BGP sessions must be set to the /31 value of the IP address of the router interface used to terminate the GRE-SDP tunnel packets.