One document matched: draft-lee-nsc-verification-problem-statement-00.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>

<rfc category="info" docName="draft-lee-nsc-verification-problem-statement-00"
ipr="trust200902">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>

<?rfc symrefs="yes" ?>

<?rfc sortrefs="yes"?>

<?rfc iprnotified="no" ?>

<?rfc strict="yes" ?>


  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary
if the
         full title is longer than 39 characters -->

    <title abbrev="Problem Statement for NSC Verification">
	Problem statement for Verification of Network Service Chains
	</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Seung-Ik Lee" initials="S. Lee" surname="Lee">
       <organization abbrev="ETRI">ETRI</organization>

      <address>
        <postal>
          <street>218 Gajeong-ro Yuseung-Gu</street>

          <!-- Reorder these if your country does things differently -->

          <city>Daejeon</city>

          <region></region>

          <code>305-700</code>

          <country>Korea</country>
        </postal>

        <phone>+82 42 860 1483</phone>

        <email>seungiklee@etri.re.kr</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Myung-Ki Shin" initials="M. Shin" surname="Shin">
      <organization abbrev="ETRI">ETRI</organization>

      <address>
        <postal>
          <street>218 Gajeong-ro Yuseung-Gu</street>

          <!-- Reorder these if your country does things differently -->

          <city>Daejeon</city>

          <region></region>

          <code>305-700</code>

          <country>Korea</country>
        </postal>

        <phone>+82 42 860 4847</phone>

        <email>mkshin@etri.re.kr</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    
    <author fullname="Yoon-Chul Choi" initials="Y. Choi" surname="Choi">
      <organization abbrev="ETRI">ETRI</organization>

      <address>
        <postal>
          <street>218 Gajeong-ro Yuseung-Gu</street>

          <!-- Reorder these if your country does things differently -->

          <city>Daejeon</city>

          <region></region>

          <code>305-700</code>

          <country>Korea</country>
        </postal>

        <phone>+82 42 860 5978</phone>

        <email>cyc79@etri.re.kr</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="July" year="2013" />

    <!-- If the month and year are both specified and are the current ones,
xml2rfc will fill
         in the current day for you. If only the current year is specified,
xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it
is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not
specified for the
	 purpose of calculating the expiry date).  With drafts it is normally
sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF.
-->

    <keyword>Internet Draft</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
			This document addresses the possible conflicts between service overlays in the 
			network service chaining. These conflicts are due to overlapping in classification 
			rules and resource sharing of service overlays. The verification of service chains 
			provides a method for network administrators to detect such conflicts and correct a 
			problematic service chain before applying it on the real network.
		  </t>
    </abstract>
  </front>

  <middle>
	<!-- Section 1 -->
    <section title="Introduction">
			<t>
			The current network service model is bound to static topologies and manually 
			configured resources. This has motivated a more flexible deployment model which 
			orchestrates the service delivery separated from the network. Network service 
			chaining (NSC) <xref target="I-D.quinn-nsc-problem-statement"/> 
			<xref target="I-D.boucadair-network-function-chaining"/>  
			provides a new network service model that delivers the traffic along the predefined 
			logical paths of network services (i.e., service overlays or service chains). 
			The service overlay provides a specific order of network services with no regard 
			of network topologies. The traffic is classified with a set of rules in different 
			granularity to select a target service overlay.
			</t>
	
			<t>
			The service overlays are configured to be isolated from each other with virtualization 
			of the network resources and different traffic classification rules. 
			However, the service overlays can share the physical network resources 
			(i.e., network services); and the traffic classification rules can overlap each other.
			This may cause unexpected QoS degradation in a composite network service due to network 
			service overload; and service failure due to loops or interventions of the service overlays. 
			In order to these conflicts of service overlays over network resources and classification 
			rules, it is required to verify the newly added service overlays before applying them 
			on the real network.
			</t>
	
			<t>
			This document formulates the problems in network service chaining for the 
			verification of service overlays to avoid any conflicts between them. 
			</t>
		</section>
		  
  <!-- Section 2 -->  
  	<section title="Problem Areas">
      <t>
			The main reasons why service chains may bring conflicts between each 
			other are as follows:
			</t>

			<t>
				<list style="format %d.">
					<t>
					Sharing of network services: The service overlay provides the identifiers 
					of network services; and invocation orders and logical links between them. 
					The network service is instantiated with the identifier so that one or more 
					physical network service nodes are located for it. While the network 
					service instantiation can be orchestrated by NSC functions in a load balanced 
					manner, the computing resource for the network service is limited and dynamic 
					so that it is not avoidable for different service chains to share the same 
					network service instances. This brings uncertainty in QoS of the network 
					service chains because they cannot see which service chains share the same 
					network services. Thus, the network administrator should carefully check 
					the conflict over the network resources before adding a new service chain to 
					the real network for its stability.
					</t>
					
					<t>
					Overlapping of classification rules: An incoming packet (or traffic) is 
					classified according to the classification rules to determine which service 
					overlay will handle it. The classification is based on the contents of 
					one or more packet header fields so that the classification rule may vary 
					in different granularity. This may bring a problematic case that an 
					incoming packet matches two or more classification rules with different 
					service chains, which can result in a service chain loop or intervention. 
					Different priorities of the rules can help the problem but it is not 
					easy to predict which rules may be in a conflict. Moreover, the service 
					chains of low priorities may be unreachable but not intended to. 
					Thus, the network administrator should carefully check the conflict of 
					the classification rules between service chains before adding a new one to 
					the real network for its consistency.
	
					</t>
				</list>
			</t>
				
  	</section>

  


	<!-- Section 3 -->
		<section title="Verification of Service Chains">
		<t>
		The service chain verification function provides an ability to check 
		whether there is any conflict between a new service chain and the 
		existing ones in the network before applying the new service chain in 
		the network. The aforementioned problems arise from the rule or resource 
		conflicts between service chains. Thus, the verification targets are 
		the classification rules and network resources used for a new service chain. 
		</t>

		<t>
		As a result of the rule verification, the classification rules whose 
		target packets are a subset or a superset of the ones of the new rule 
		are presented out of the existing rules in the network. In the similar 
		way, the shared network services between the new service chain and the 
		existing ones are listed with their frequencies of being shared as a 
		result of resource verification. The verification results are provided 
		to network administrators so that they can easily anticipate the possible 
		problematic cases and determine if the service chain is required to be 
		corrected or not.
		</t>

		<t>
		The verification procedure above is performed in an off-line manner. 
		In other words, it is a formal verification method which checks the 
		conflicts of configurations at design time. This method is relatively 
		simple and can test a set of service chains in an exhaustive manner. 
		However, dynamic state of network resources and topologies cannot be 
		considered at the verification.
		</t>

	</section>


    <!--section anchor="Acknowledgements" title="Acknowledgements">
      <t>This template was derived from an initial version written by Pekka
      Savola and contributed by him to the xml2rfc project.</t>

      <t>This document is part of a plan to make xml2rfc indispensable <xref
      target="DOMINATION"></xref>.</t>
    </section-->

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Security" title="Security Considerations">
      <t>
	  	TBD.
	  </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
      TBD.
      </t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation
libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
(as shown)
     2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here
        (for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included
files in the same
     directory as the including file. You can also define the XML_LIBRARY
environment variable
     with a value containing a set of directories to search.  These can be
either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    &rfc2119;		
	</references>

    <references title="Informative References">
     <!-- A reference written by by an organization not a person. -->
			
    <reference anchor="I-D.quinn-nsc-problem-statement">
      <front>
        <title>Network Service Chaining Problem Statement</title>

        <author fullname="P. Quinn" initials="P." surname="Quinn">
          <organization></organization>
          </author>
          
        <author fullname="J. Guichard" initials="J." surname="Guichard">
          <organization></organization>
          </author>          
         
        <author fullname="S. Kumar" initials="S." surname="Kumar">
          <organization></organization>
          </author>                    

        <date month="July" year="2013" />
      </front>

      <seriesInfo name="" value="draft-quinn-nsc-problem-statement-01" />
    </reference>
    
    <reference anchor="I-D.boucadair-network-function-chaining">
      <front>
        <title>Differentiated Network-Located Function Chaining Framework</title>

        <author fullname="M. Boucadair" initials="M." surname="Boucadair">
          <organization></organization>
          </author>
          
        <author fullname="C. Jacquenet" initials="C." surname="Jacquenet">
          <organization></organization>
          </author>          
         
        <author fullname="R. Parker" initials="R." surname="Parker">
          <organization></organization>
          </author>                    

        <date month="July" year="2013" />
      </front>

      <seriesInfo name="" value="draft-boucadair-network-function-chaining-02" />
    </reference>

    </references>

  </back>
</rfc>