Overview and Scope
This service-type enables a UPnP control point to configure and control PPP/IP connections on the WAN interface of a UPnP compliant InternetGatewayDevice*.
Generally, PPP Internet connections are set up from a WAN interface of the IGD to (ISPs). However, an implementation MAY support PPP connections that are bridged or relayed (as in the case of some DSL modems) through the gateway device.
All IP Internet connections are set up from a WAN interface of IGD or bridged through the gateway to (ISPs).
An instance of a WAN(PPP/IP)Connection service is activated (refer to SST below) for each actual Internet Connection instance on a WANConnectionDevice. WAN(PPP/IP)Connection service provides PPP/IP-level connectivity with an ISP for networked clients on the LAN.
A WANConnectionDevice MAY include a WAN{POTS/DSL/Cable/Ethernet}LinkConfig service that encapsulates Internet access properties pertaining to the physical link of a particular WAN access type. These properties are common to all instances of WAN(PPP/IP)Connection in a WANConnectionDevice. A WANDevice provides a WANCommonInterfaceConfig service that encapsulates Internet access properties common across all WANConnectionDevice instances.
More than one instance of WANPPPConnection service may be defined on a WANConnectionDevice – representing multiple user accounts using the same link (username / password) to an ISP.Multiple instances of this service will be distinguished based on the ServiceID for each service instance. In accordance with UPnP Architecture version 1.0, the maximum number of WANPPPConnection service instances is static and specified in the InternetGatewayDevice description document.
Theory of Operation: PPP Connection.
When a WANDevice is initialized, it is initialized with one or more instances of WANConnectionDevice depending on the number of physical links (VCs for DSL, ISPs for POTS) the gateway is configured to support.
POTS - ConnectionType - IP_Routed.
Figure 1 Connection Initiation Steps
1. A control point that wants to access Internet first scans the different WANPPPConnection service instances and retrieves the PossibleConnectionTypes and ConnectionType variables for each service. For each scanned connection, the control point first checks ConnectionType to see if the connection is already configured. If the connection is configured (the ConnectionType value is not Unconfigured), it checks if the Connection Procedure associated with the current value ofConnectionType is convenient and if the connection is really available (by checking ConnectionStatus).If the connection is not configured, the control point matches the values in PossibleConnectionTypes against the values corresponding to Connection Procedures it can support and it is interested in.
2. If PossibleConnectionTypes contains such a value, it selects it by setting the variable ConnectionType.
3. The control point then starts the Connection Procedure associated with the chosen ConnectionType value.
The Connection Procedures associated to each value of ConnectionType are described in the table below.
The table can be understood with the following algorithm:
If(PossibleConnectionTypes contains value in Column 1) and
(CP capabilities supports the corresponding value in Column 2) and
(CP wants to use this connection)
{
set ConnectionType to value in Column 1.
do list of elementary tasks in column 4.
}
type and capabilities for PPP
IP_Routed IP Stack
1 Set the default gateway address to the InternetGateway address
2 Send IP packets through the gateway
PPTP_Relay PPTP client
1 Open a PPTP tunnel to gateway and send IP packets over it.
L2TP_Relay L2TP client
1 Open a L2TP tunnel to gateway and send IP packets over it.
PPPoE_Relay PPPoE client
1 Open a PPPoE tunnel (to gateway) and send IP packets over it.
PPPoE_Bridged PPPoE client 1 Open a PPPoE tunnel (to ISP) and send IP packets into it.
DHCP_Spoofed DHCP client + IP Stack
1 Send a DHCP request and wait for the answer.
2 Send IP packets through the Internet Gateway
type and capabilities for IP
IP_Routed IP Stack
1 Set the default gateway address to the Internet Gateway address
2 Send IP packets through the gateway
IP_Bridged IP Stack
1 Get the ISP IP address (through DHCP?) and set it as the default gateway address.
2 Send IP packets to ISP IP address
2.5.1. Connection Initiation
A UPnP client sends the RequestConnection action to a specific instance of the WANPPP/IPConnection service on a particular WANConnectionDevice.to inform the gateway of its intent to use Internet access.
(IP): When a WANConnectionDevice is initialized, an instance of WANIPConnection service will be initialized. If an IP connection is automatically initiated i.e. ‘always on’ as soon as the underlying link is up, no action is needed from a UPnP control point to initiate the connection. However, the IP connection may be become inactive (Disconnected) because of network or server issues.
A UPnP client initiates a PPP connection in one of the following ways
• ConfigureConnection command followed by RequestConnection to a connection instance in the Unconfigured connection state. In this case the configuration would be available for other clients to use, if it is not explicitly cleared from the SST when the connection becomes Disconnected.
• RequestConnection command to a Disconnected (but configured) connection.
A client desiring to use an already active connection would send the RequestConnection command to a specific instance of WANPPPConnection service that is Connected. If this command is sent to a connection that is not previously configured or improperly configured, the client will be notified with an appropriate error code. This is also the case if the WANPPPConnection service is used to request a connection before the corresponding Link Configuration service is configured - For e.g., VC info in WANDSLLinkConfig service for DSL, Phone number in WANPOTSLinkConfig service for POTS.
PPP-IP
When a client sends a RequestConnection command to a Disconnected (but configured) connection, the WANConnectionDevice initiates the connection to ISP may transition through optional intermediate connection states (Authenticating and Connecting) and eventing on these states is implementation dependent. Depending on whether the connection is successful, ConnectionStatus is changed to Connected or Disconnected. A client may retrieve LastConnectionError in case of connection failure.
When a connection service gets a RequestConnection command, if the ConnectionStatus is:
• Connecting, (Authenticating-PPP) or Disconnecting: an error is returned.
• Disconnected: a connection is attempted (ConnectionStatus may transition to Connecting).
If this is successful, ConnectionStatus changes to Connected.
• PendingDisconnect: it is changed to Connected.
• Connected: the client is allowed to use the connection if ConnectionType is IP_routed,
otherwise an error is returned.
IP State Diagram
PPP-State Diagram
RequestConnection may fail (causing an error code to be returned) under the following conditions:
1. Network failure (in reaching the ISP-PPP)
2. ISP login failure - PPP
3. ConnectionStatus is Connecting, (Authenticating or Unconfigured-PPP)
4. Corresponding Link interface configuration service was not yet configured-PPP
5. EnabledForInternet variable in WANCommonInterfaceConfig is set to 0 (false)
LastConnectionError will indicate the cause of error if connection setup fails due to error conditions
1 or 2 above.
The connection set up may be aborted by a client (by issuing RequestTermination or
ForceTermination)
Connection Termination
Connection Termination can be explicit (by a client sending RequestTermination or ForceTermination action) or implicit (because of AutoDisconnectTime or IdleDisconnectTime coming into effect).
A UPnP client sends RequestTermination or ForceTermination action to a specific instance of the WANPPPConnection service on a particular WANConnectionDevice to inform the gateway that the PPP connection to the Internet should be terminated. for IP Connection termination is accepted when the ConnectionType is IP_routed and ConnectionStatus is Connecting or Connected.
A connection termination may be initiated due to:
(PPP)
1. A RequestTermination or ForceTermination command from a client
2. AutoDisconnectTime or IdleDisconnectTime coming into effect
3. A deployment specific Gateway policy
4. EnabledForInternet variable (in WANCommonInterfaceConfig service) being set to 0
5. An ISP initiated connection termination or network failure
At this point ConnectionStatus transitions (resulting in notification to clients registered for this
event) immediately to one of the following:
• PendingDisconnect (if RequestTermination is implemented in the gateway and called by a client): This occurs if WarnDisconnectDelay is non-zero and the cause for termination is 1or 2 (as mentioned above). The PPP/IP connection is still active in this state. This is useful for giving clients using a connection a chance to react when a connection termination is in progress. If the termination is due to a Gateway policy (3 above), a specific implementation of the Gateway may chose to warn the clients by transitioning to this state.
o If clients choose to ignore the notification, the connection will be terminated after the time (in seconds) specified as WarnDisconnectDelay. ConnectionStatus transitions to Disconnecting.
o If any client sends RequestConnection command at this point, the gateway MAY choose to discontinue the termination process by changing ConnectionStatus to Connected. If connection is not restored, the gateway will return error code indicating
that the connection was in the process of being torn down.
• Disconnecting –this can happen in the following cases –
o ForceTermination command was called
o RequestTermination called, and if no other clients are using the connection, the gateway may choose to skip PendingDisconnect state.
o WarnDisconnectDelay is zero and the cause for termination is RequestTermination or 2 (as mentioned above).
o termination was triggered by EnabledForInternet variable being set to 0
o termination was triggered by ISP
o termination occurred due to a Gateway policy, and the specific implementation chose not to warn the clients by switching directly to this state – essentially overriding the value of WarnDisconnectDelay.
When transitioning to this state, the PPP/IP connection is inactive immediately.
• Disconnected – if the above two optional states are not implemented.
If the connection state is Connecting when a client issues a RequestTermination, the state transitions to Disconnected directly – it does not go to PendingDisconnect even if WarnDisconnectDelay is non-zero. As mentioned before, in the case of termination because of a Gateway policy the action (whether clients are warned or not) depends upon the gateway implementation.
When a client receives a PendingDisconnect notification, it can do one of two things:
• Ignore it and let the disconnect proceed
• Send a RequestConnection command – the client can keep the connection from disconnecting – this is implementation dependent as pointed out earlier.
Connection Scenarios
As previously mentioned, the possible connection types for a WANPPPConnection are IP_Routed, DHCP_Spoofed, PPPoE_Bridged, PPTP_Relay, L2TP_Relay, and PPPoE_Relay, and for a WANIPConnection are IP_Routed and IP_Bridged.
The connection scenarios for these different types of connections and the role of connection related actions are described in more detail below.
2.5.3.1. IP_Routed
In this scenario, some pre-configuration may be required for a WANPPPConnection. A control point (CP) may use the ConfigureConnection (optional) action to setup the connection parameters such as username and password.(no priori configuration for WANIPConnection.
If the IP_Routed connection is the default connection on the IGD a CP on the LAN that desires to use the connection is not required to send the RequestConnection action even if the connection is not active. If the connection is configured but inactive, the IGD will initiate a WAN connection upon receiving any outbound packets from the CP (assuming the ‘dial-on-demand’ option is enabled on the IGD) or upon receiving a RequestConnection action. This may translate to a PPP connection setup and configuration via IP Configuration Protocol (IPCP). (for IP - IGD obtaining an IP address via DHCP from the ISP. ) It results in a transition of ConnectionStatus to active. The IGD shares the routable WAN IP address with CPs on the LAN using Network Address Translation (NAT). The CPs on the LAN are assigned private IP addresses in response to their DHCP requests (CPs may self-assign non-routable IP addresses in certain IGD configurations). If the IGD supports multiple WAN connection instances, the RequestConnection action is intended for a CP to specify a WANPPP/IPConnection instance (that in all likelihood is different from the default connection).
A CP may use RequestTermination or ForceTermination to disconnect the IGD from the
WAN (this involves releasing any previously acquired IP resources from the ISP).
RequestTermination: A CP can invoke this action, if available, to terminate an active connection. As an example, if three CPs were sharing a WAN connection instance and if each were to call RequestTermination, the IGD may release IP resources acquired from the ISP on the three instances of RequestTermination to conserve IP resources. If WarnDisconnectDelay is implemented and is non-zero the IGD is required to change the ConnectionStatus from Connected to PendingDisconnect and wait until WarnDisconnectDelay seconds elapse before transitioning to the Disconnected state.
ForceTermination: The IGD will immediately release all WAN IP resources, disregarding the value of WarnDisconnectDelay variable.
An example of an implementation of this connection type is an (routing(IP))IGD modeling a PC or embedded gateway with a(Cable modem (IP)) POTS modem as a WAN interface.
2.5.3.2. IP_Bridged
In this scenario, all Ethernet packets from a CP on the LAN are bridged to the WAN by the IGD. If this were the default connection, all Ethernet traffic across all LAN interfaces will be bridged to the WAN side. The actions RequestConnection, RequestTermination and ForceTermination are not relevant in this case since the IGD is not IP addressable by the CP over the LAN. If this were not the default, a CP may use the RequestConnection action to select a specific WAN
connection instance, followed typically by a DHCP renewal request. All Ethernet packets (including DHCP requests) from this CP get redirected (bridged) through the default WAN connection. This assumes that that the IGD is capable of source (MAC) address based bridging. The CP that is actively using the connection may issue RequestTermination or ForceTermination actions through a secondary interface (if the CP is multi-homed) to end the use of this connection and change the ConnectionStatus to inactive. Alternatively, a CP that is not using the connection may issue RequestTermination or ForceTermination to disconnect IGD from the WAN.
An example of an implementation of this scenario would be a bridging IGD with an integrated Cable modem on the WAN interface that, in turn, has an Ethernet link to CM Termination System (CMTS).
If an IGD supports multiple WAN connection instances and has one active (IP) bridged connection, it cannot allow other WAN connections to be simultaneously active unless it supports source (MAC) address based bridging on that bridged connection, where the source MAC address identifies a CP. The RequestConnection action returns an error if this were the case.
2.5.3.2. DHCP_Spoofed
This scenario may require some a priori configuration that is similar to the IP_Routed case. It is mostly applicable to cases where the WAN connection type is PPP and LAN connections are based on IP. If this is the default connection instance, a CP on the LAN need not invoke the RequestConnection action prior to initiating any communication to the WAN, even if the ConnectionStatus is not active. The IP address obtained via IPCP or DHCP from the ISP is relayed back as a DHCP response to a CP on the LAN. The IP address may be obtained a priori (as would be the case for “always-on” connections) or may be obtained via a dial-on-demand connection. The relaying of the routable IP address to a CP results in the transition of ConnectionStatus to active. Subsequently, the IGD essentially forwards packets to and from the CP. If a connection were already active, the CP is returned a private IP address for its DHCP request – this implies that that CP would be unable to communicate to nodes on the WAN. This connection type essentially creates an implicit one-to-one binding between a CP on the LAN and a routable IP address on the WAN, making it virtually impossible for other CPs to share the connection.
Furthermore, a CP that supports DHCP_Spoofed connections must support dual-homing with the other “interface” bound to an appropriate private IP address to be able to continue IP (UPnP) communications with the IGD after it is assigned a routable IP address. A CP that is actively using a DHCP_Spoofed connection may issue a RequestTermination or ForceTermination action through a secondary interface (if the CP is multi-homed) to end the use of this connection. Alternatively, a CP that is not using the connection may issue RequestTermination or ForceTermination to disconnect the IGD from the WAN. The termination actions result in ConnectionStatus being changed to inactive - ceasing packet flow on the link. Also, it is assumed that the IGD is capable of source address based routing, necessitated by the implicit mapping of a CP to a WAN IP address.
If this were not the default connection, the CP may get a private IP address for a normal DHCP request.
The CP may then use the RequestConnection action to notify the IGD that it intends to reserve the DHCP_Spoofed WAN connection to itself. If the connection is already active, IGD returns an error. If this action is successful, when the CP resends its DHCP request it will be assigned a routable WAN IP address. Ending the use of the connection would require the CP to issue RequestTermination or ForceTermination as mentioned before.
An example of an implementation of this scenario would be an IGD with an integrated DSL modem on the WAN interface that implements PPPoA on one of its virtual circuits.
2.5.3.3. PPPoE_Bridged
In this scenario, the CP on the LAN initiates a PPP session to the WAN (bridged through IGD) and gets a routable IP address via IPCP instead of DHCP. All Ethernet packets from the CP on the LAN are bridged to the WAN by the IGD. Packets from other clients will not be bridged over this connection.
A CP may use the RequestConnection action to select a specific WAN connection instance, followed typically by a PPP connection request. All Ethernet packets (including IPCP requests) from this CP get redirected (bridged) through the default WAN connection. This assumes that that the IGD is capable of source (MAC) address based bridging. The CP that is actively using the connection may issue RequestTermination or ForceTermination actions through a secondary interface (if the CP is multi-homed) to end the use of this connection and change the ConnectionStatus to Inactive. Alternatively, a CP that is not using the connection may issue RequestTermination or ForceTermination to disconnect IGD from the WAN.
A PPPoE_Bridged session that is initiated on the WAN interface of an IGD is modeled differently. In this case, multiple IP sessions from CPs on the LAN may be routed/NAT’ed over a single PPPoE_Bridged connection. A WANPPPConnection with the ConnectionType set to IP_Routed will model this scenario.
2.5.3.4. PPTP_Relay, L2TP_Relay, PPPoE_Relay In each of these scenarios, the LAN CP initiates a PPP connection to the WAN but essentially tunnels these packets to the IGD over an Ethernet/IP LAN link. The IGD de-tunnels and forwards the packets on the WAN (via PPPoA). However, the behavior of the LAN CP and usage of connection related actions is similar to that of an IP_Bridged connection.
If an IGD supports multiple WAN connection instances and has one active (PPP) bridged connection, it cannot allow other WAN connections to be simultaneously active unless it supports source (MAC) address based bridging on that bridged connection, where the source MAC address identifies a CP. The RequestConnection action returns an error if this were the case.
2.5.4. Non-UPnP compliant clients
The gateway SHOULD support non-UPnP compliant devices by making it is possible for a client to start accessing the Internet (effectively Dial-on-Demand) without sending RequestConnection command.
The client in this scenario cannot specify which particular WANConnectionDevice or WANPPPConnection it wants to use. The WANPPP/IPConnection to be used is identified using the DefaultConnectionService identified in Layer3Forwarding service. Also, the client will not be able to terminate the connection or use the other features of WANPPP/IPConnection service (like detecting connection speed or port mapping).
2.5.5. VPN connections
VPN sessions may be established on a PPP connection initiated at the gateway. There are 2 cases to consider:
o A client on the residential LAN initiates a VPN session. In this case, the VPN is transparent to the WANPPPConnection instance and is not visible in the UPnP context.
o A VPN client is initiated on the gateway. In this case, the VPN session would use a WANPPPConnection instance. A VPN service to model this scenario is not standardized in this WC – it is possible however, as a vendor extension. One possible way to do this is to provide a VPN service in InternetGatewayDevice outside of WANDevice. The state table for this service would support configuration attributes that are essential for setting up a VPN connection. These would include parameters such as
o IP address(es) of VPN Gateway
o Security Protocols to be used
o Authentication and Privacy parameters specific to a security protocol
o Session time-out delay
In addition, it would also contain a ConnectionService variable that specifies a WANPPPConnection service instance in a WANConnectionDevice. A comma-separated 2-tuple uniquely identifies the service:uuid:device-UUID:WANConnectionDevice:v , urn:upnp-org:serviceId:serviceID.
The VPN service would support a RequestConnection action that would in turn invoke the RequestConnection of the corresponding WANPPPConnection service like any other UPnP client.
