z/OS Communications Server: SNA Network Implementation Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Traversing multiple APPN network boundaries

z/OS Communications Server: SNA Network Implementation Guide
SC27-3672-01

To enable an EE connection network to traverse multiple APPN network boundaries, you can create an EE global connection network. In an EE global connection network, the following are true:
  • An IP wide area network (WAN) is a shared access transport facility (SATF) represented by a global virtual routing node (GVRN).
  • Nodes can indicate their connectivity to the SATF through the GVRN, thereby enabling nodes in the same or different APPN subnetworks to establish direct connectivity without having explicit routes (TGs) defined to one another.
  • Part or all of a session path can traverse a common IP network (intranet or internet) and can bypass the extended border nodes (EBNs) completely.
  • The computed session route does not have to traverse the adjacent border nodes (which is required when global VRNs are not used). This often provides for more optimal session routes and can remove the EBNs as a potential data bottleneck.
A GVRN can be used for cross-network EE connections if the following are true:
  • The GVRN must be defined in the subnetwork of the proposed session endpoints.
  • The GVRN must be defined on the endpoint node; or on the EBN that is acting as the entry point into (or exit point out of) the subnetwork of the endpoint node; or, under certain circumstances, on a network node in the subnetwork of the PLU. A GVRN defined on a network node can be used when that network node is in the same subnetwork as the PLU and the final session route is calculated by PLU node's network node server.
  • The session path is completely APPN, and every subnetwork boundary along the session setup path is an extended subnetwork boundary. (That is, there is an EBN on both sides of every subnetwork boundary.) Each of the EBNs on the session setup path must be z/OS® V1R2 Communications Server or later VTAMs.
Restrictions: The following restrictions apply when an EE global connection network is used for session establishment.
  • GVRNs do not allow dynamic connections to end nodes residing below a branch extender node (BrNN). Assuming the BrNN has a connection to the GVRN, the BrNN is the concentration point for the EE global connection network for all nodes residing downstream of the BrNN.
  • A GVRN is not used in intermediate subnetworks along a session setup path (except, possibly, as a local VRN).
  • In most cases, a GVRN is not used if either session endpoint resides in or the session path traverses a subarea network (through an interchange node). However, the use of a DSME in intermediate border nodes might allow using a GVRN when the SLU resides in or the session path traverses a subarea network.
  • GVRNs are not used for session setup requests that traverse APPN subnetwork boundaries defined with the value RTPONLY=YES. (The value RTPONLY=YES enables border nodes to maintain awareness of all sessions established over the specified APPN subnetwork boundaries; but using a GVRNs instead could result in an EBN not maintaining awareness of one or more sessions, which would defeat the purpose of RTPONLY=YES.) For more information about the RTPONLY operand, see RTPONLY operand in z/OS Communications Server: SNA Resource Definition Reference.

Rules for identifying the source of the local IP address associated with a connection network:

  • Each connection network partner must identify the IP address associated with its endpoint on the connection network. Specify either the host name or the IP address on the group definition where the connection network is defined.
  • If the connection network represents an IPv6 network, then the connection network endpoint address must be specified using the HOSTNAME parameter.
  • If the connection network represents an IPv4 network, then the endpoint can be defined by either the IP address parameter or the HOSTNAME parameter; however, the HOSTNAME parameter provides maximum flexibility because it provides compatibility with networks that use network address translation (NAT).

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014